How to test core web vitals

Record a page load in the Chrome DevTools Performance panel, then read the LCP, CLS and INP values it reports and compare them with the field data for the same URL. Lab and field numbers differ, so a page passes only when the field numbers at the 75th percentile stay inside Google's thresholds.

Why check this

Core Web Vitals sit in the release gate of any page that search traffic reaches, and they are the performance numbers a product owner quotes back at you. Run the check on staging before a release, then again on production once real traffic has accumulated. The failure it prevents is concrete: a tester signs off a page on a fast laptop with a warm cache while real users on the same URL wait almost four times longer for the main content to appear.

Prerequisites

• Chrome with DevTools. Read your own build from chrome://version and record it next to your numbers, because the Performance panel changes between versions.
• The exact URL under test, query string included. Field data is keyed by URL.
• curl 8 or later for step 1. See the curl manual.
• The metric definitions and thresholds on web.dev Web Vitals.

Steps

1. 1

   Step 1.

   Measure the server side first, so you know how much of the budget is gone before the browser paints anything.

   curl -s -o /dev/null -w 'code %{http_code}\nttfb %{time_starttransfer}\ntotal %{time_total}\nbytes %{size_download}\n' https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS
   

   code 200
   ttfb 0.207413
   total 0.344199
   bytes 258732

   This is the pre-filter. It tells you the document arrives and how long that takes from your network. It reports none of the three vitals, because all three are measured inside the browser.

2. 2

   Step 2.

   Open the URL in Chrome, press F12, switch to the Performance panel and click the reload and record button. Wait for the trace to stop, then read the LCP marker and the layout shift track.

   LCP  375 ms
   TTFB          2 ms
   Render delay  374 ms
   CLS  0.00

   One capture of one load on one machine. Your own trace produces its own numbers.

3. 3

   Step 3.

   Read the field data for the same URL, from the field section of the Performance panel or from PageSpeed Insights. Both read the same Chrome User Experience Report dataset.

   Field (CrUX, p75 of real Chrome users, scope: url)
   LCP  1363 ms
     TTFB          336 ms
     Load delay    633 ms
     Load duration 299 ms
     Render delay  161 ms
   INP  35 ms
   CLS  0.05

How to read the result

| What you see | What it means | What to do | | --- | --- | --- | | Lab LCP 375 ms, field LCP 1363 ms | Your machine and your cache are faster than the user population | Report the field number. Keep the lab number as the reproduction. | | Field CLS 0.05 while lab CLS is 0.00 | The shifts follow interactions the trace never made | Scroll and click during the trace, then read CLS again. | | Field INP 35 ms | Interaction cost is inside the threshold on this URL | Nothing. INP has no lab equivalent to chase. | | No field section for the URL | CrUX has too few samples for this page | Read the origin scope instead, and say in the report which scope it is. |

Common mistakes

Thresholds

What to check next

• How to check LCP of a page: LCP is the metric that fails first, and its subparts name the stage to fix.
• How to check CLS: the metric a load-only trace under-reports, and how to make the trace see it.
• How to check render blocking resources: the usual suspect behind a long render delay.
• How to check if images are lazy loaded: lazy loading cuts requests and can also delay the LCP image.
• How to check TTFB: the first subpart of LCP, and the one the backend owns.
• How to check HTTP response headers with curl: the cache headers that explain a 2 ms lab TTFB.

FAQ

How to measure core web vitals without Chrome?

Field data comes from Chrome users only, so no other browser contributes to it. You can time a page anywhere with your own instrumentation, and the number will be valid for your own report, but it is not the number Search uses.

What is the difference between lab and field core web vitals data?

Lab data is one load on your machine, under your network and your cache state. Field data is the 75th percentile of real Chrome users. On the captured URL the same metric read 375 ms in the lab and 1363 ms in the field. Lab finds causes, field decides pass or fail.

How to check INP?

INP appears in the field section only. It needs real interactions, and a load trace makes none. The captured URL reported INP 35 ms in the field and no INP value in the lab. To debug it, record a trace while clicking the slow control.

Which number belongs in the bug report?

The field value, with its scope label and the date beside it. Put the lab value underneath as the reproduction. A report that quotes the lab number alone gets closed as not reproducible on the developer's machine.

Verified

The browser figures above come from one Chrome DevTools capture of https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS on 2026-09-11, on one machine, with no CPU and no network throttling. That is a single capture and not a benchmark. Read your own Chrome build from chrome://version and record it beside your own numbers.