How to measure Core Web Vitals: tools compared

Two kinds of data

Every speed tool gives you one of two kinds of number, and most of the confusion about Core Web Vitals comes from mixing them.

Google judges the Core Web Vitals on field data. That is why a page can score 100 in a lab test and still fail: the test is a fast, patient visitor, and real visitors are not.

Step 1: check whether a page passes

Open PageSpeed Insights, enter the address and choose the Mobile tab first, because most sites are weaker there. The report has two parts.

• "Discover what your real users are experiencing" is the field data, taken from the Chrome UX Report (CrUX) for the last 28 days. It shows LCP, INP and CLS for the page, with the share of visits that were good, needing improvement and poor, and an assessment of passed or failed. If there is not enough data for the page itself, PageSpeed Insights shows data for the whole site and says so, so check which one you are reading.
• "Diagnose performance issues" is the lab data: a Lighthouse test run for you. It has the performance score and a list of insights and diagnostics that point at causes.

Read the top part for the answer and the bottom part for ideas. The big number in the lab part, the performance score from 0 to 100, is not what Google uses to decide whether you pass.

Step 2: see which pages are affected

PageSpeed Insights looks at one address at a time. The Core Web Vitals report in Google Search Console covers the whole site: it groups your URLs by status for mobile and for desktop and lists the issues that keep URLs out of the good group, so you can see which kinds of page to look at first. It uses the same real-user data, and it only has data for pages with enough visits.

Step 3: find the cause with a lab test

Run Lighthouse (the Lighthouse guide covers each way), either in PageSpeed Insights, in the Lighthouse panel of Chrome DevTools, or from the command line. Know what the default test assumes, because it explains the numbers you get:

• Mobile. A phone about as capable as a Moto G Power, a screen 412 pixels wide, a network simulated at 1.6 megabits per second with 150 milliseconds of latency (Lighthouse calls it "Slow 4G", roughly the 75th percentile of 4G connections), and a processor slowed by a factor of four.
• Desktop. A 1,350 pixel wide window, 10 megabits per second with 40 milliseconds of latency, and no processor slowdown.

Lighthouse does not slow your real network: it loads the page and then calculates what would have happened on the slower one. That is why the lab results are repeatable and why they still differ a little from run to run. Run the test three times and use the median.

Once the lab test points at a failing metric, read the guide for it: LCP for slow loading, INP for slow reactions and CLS for a page that jumps. A standard lab test cannot measure INP at all, because nobody taps anything during the load. Lighthouse reports Total Blocking Time instead, which tends to move together with it.

For a question about something you can see happening, such as a button that reacts late, use Chrome DevTools. Its Performance panel records a load or an interaction and shows the main thread, the layout shifts and the interaction timings. The live metrics view shows LCP, CLS and INP as you click through the page.

Step 4: measure your own real visitors

The Chrome UX Report is a large sample, not all of your visitors (see the CrUX guide). It includes Chrome users on desktop and Android who share usage statistics, and it leaves out Chrome on iOS, other Chromium browsers such as Edge, and WebView apps. To see every browser, and to find out which element and which script caused a slow result, collect the numbers yourself with Google's open-source web-vitals library. It is small, and each of its callbacks runs once a metric is ready:

import {onLCP, onINP, onCLS} from 'web-vitals/attribution';

function send(metric) {
  navigator.sendBeacon('/vitals', JSON.stringify({
    name: metric.name,        // LCP, INP or CLS
    value: metric.value,
    rating: metric.rating,    // good, needs-improvement or poor
    id: metric.id,
  }));
}

onLCP(send);
onINP(send);
onCLS(send);

The attribution import adds the diagnostic details: for INP, the element that was touched and the three parts of the delay; for LCP, which element it was and the four parts; for CLS, which elements shifted. sendBeacon can send data while the page is being closed. Your server only needs a small endpoint that stores the lines, or you can send the data to an analytics tool you already use.

Other sources of the same data

The Chrome UX Report is also available in other forms. The CrUX API gives page-level and site-level data, updated daily from the previous 28 days. The CrUX Dashboard and BigQuery tables are updated monthly and show the history since 2017 at site level. They are useful for trends and for comparing against competitors' public sites, and less useful for a fix you made this week.

Which tool for which question

A simple routine

1. Check the field data for mobile in PageSpeed Insights. Note which of the three metrics is not good.
2. Run the lab test three times and read the insight that matches the failing metric.
3. Fix the biggest cause. Change one thing at a time.
4. Run the lab test again to confirm the cause is gone.
5. Check the field data again after four weeks, because that is when the real visits catch up.

Check your own page

Run the free audit for the lab and field view of your page in one report. Then compare the real-user numbers with the lab numbers: if the lab looks good and the field does not, your visitors have slower devices or networks than the test, or they do things after the page loads that the test never does.

Sources

• Web Vitals on web.dev: the field and lab distinction and the tools that report each.
• Chrome UX Report methodology: who is in the data, how often it updates and the tools that expose it.
• The web-vitals library: usage, the attribution build and the analytics example.
• Lighthouse overview: the ways to run Lighthouse.