Why measure Web Vitals at all

You can't improve what you don't measure. That maxim applies directly to Web Vitals: before you can optimize Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), or Interaction to Next Paint (INP), you need a data collection strategy. A well-rounded approach covers both field data from real users and lab data from controlled environments.

Getting started does not require major engineering effort. Most of the recommended tooling is free, and the code changes needed to collect your own real-user monitoring (RUM) data are minimal.

Start with real-user data

Field data — collected via Real User Monitoring (RUM) — captures the performance your actual visitors experience. This is the data Google uses to evaluate whether a site meets the recommended Core Web Vitals thresholds.

If you have no RUM setup in place, several tools can get you field data quickly. They all draw from the same underlying dataset, the Chrome User Experience Report (CrUX), but serve different purposes:

  • Chrome DevTools — the Performance panel's live metrics view pulls CrUX data for the page you're debugging, letting you compare your local experience against what real users see.
  • PageSpeed Insights (PSI) — reports aggregate page-level and origin-level performance for the past 28 days, and offers suggestions for improvement. Available on the web and as an API.
  • Search Console — reports performance per page, which makes it useful for identifying specific pages that need attention. It also includes historical data. Note that you must own and verify the site to use it.
  • CrUX Vis — a prebuilt dashboard built on the CrUX History API that surfaces historical CrUX data for a URL or origin. It includes more granular details than PSI or Search Console, such as LCP subparts and navigation types. Setup takes about a minute.

These CrUX-based tools are fine as a starting point, but they are also useful beyond that: both CrUX and PSI expose APIs that can power custom dashboards and reporting.

Collecting your own RUM data

While CrUX-based tools give you a good baseline, they are no substitute for your own RUM implementation. Data you collect yourself is more immediate and more detailed, which makes it easier to spot regressions and test fixes.

You have two main options: use a dedicated RUM provider, or build your own reporting. If you already have a RUM vendor, ask whether they support Core Web Vitals monitoring. If you don't, you can often extend an existing analytics setup with the help of the web-vitals JavaScript library.

The web-vitals library

For a do-it-yourself RUM setup, the web-vitals library is the simplest path. It's a small (~2KB), modular library that provides a convenient API for collecting and reporting each of the field-measurable Web Vitals metrics.

The library exists because Web Vitals metrics aren't all directly exposed by browser performance APIs — they're built on top of them. CLS, for example, is implemented using the Layout Instability API. Using web-vitals saves you from implementing the metrics yourself and ensures your data collection matches established methodology.

Reporting and aggregating

Collecting measurements is only half the job — you must also report them. The web-vitals documentation includes examples for sending results to a generic API endpoint, Google Analytics, or Google Tag Manager.

If you don't have a preferred reporting tool, Google Analytics is free and works well for this purpose. When choosing a tool, think about who needs access to the data. Performance improvements tend to be most successful when the whole company is engaged, not just a single team.

Reading the numbers right

When analyzing performance data, pay attention to the distribution's tails, not just the middle. RUM data often shows wide variation: some users have fast experiences, others slow ones. A median or average can hide that spread.

Google's evaluation criteria reflect this. A site or page is considered to meet Core Web Vitals thresholds when 75% of page visits hit the "good" threshold for each metric — not when the average experience is good.

Complement with lab data

Lab data, also called synthetic data, comes from a controlled environment rather than from real users. Its key advantage: it can be collected from pre-production environments, which means it can be wired into developer workflows and continuous integration pipelines. Lighthouse and WebPageTest are common examples.

Some discrepancies between field and lab data are expected — network conditions, device types, and geography differ. But for the Web Vitals metrics specifically, a few systematic differences are worth noting:

  • LCP measured in the lab can differ from field LCP due to redirects, server connection latency, uncached resources, and content variations (such as cookie banners or personalization) that depend on the user.
  • CLS measured in the lab tends to be artificially low. Many lab tools load the page but never interact with it, so they only capture layout shifts during initial page load. RUM data captures unexpected layout shifts across the entire lifespan of the page.
  • INP cannot be measured in the lab at all, since it requires real user interactions. Total Blocking Time (TBT) is the recommended lab proxy. INP and TBT are calculated differently, but both reflect a blocked main thread during page bootstrap — when the main thread is blocked, the browser can't respond to user input.

Lab tooling

Several tools can gather lab measurements of Web Vitals:

  • Chrome DevTools — the Performance panel reports Core Web Vitals for the loaded page in its live metrics view, giving real-time feedback as you make code changes.
  • Lighthouse — reports on LCP, CLS, and TBT, and points out possible performance improvements. It's available in Chrome DevTools, as an npm package, and can be integrated into CI workflows with Lighthouse CI.
  • WebPageTest — includes Web Vitals in its standard reporting and is particularly useful for testing under specific device and network conditions.