Core Web Vitals report

Field data and lab data are two different things

A lab test, such as Lighthouse, loads your page once on a simulated mid-range phone with a throttled connection. You can repeat it as often as you like and it’s full of detail, but the visitor it describes is imaginary.

Field data comes from real visits. Chrome users who agreed to share usage statistics send anonymous timings, and Google aggregates them over the last 28 days in the Chrome UX Report, known as CrUX. This is the data Google Search reads when it evaluates page experience. A page can score 95 in the lab and still fail in the field because its real audience is on older phones. It can also pass in the field with a mediocre lab score because most visitors arrive with a warm cache.

This report asks for field data first, since that’s the version that counts.

The five timings in the table

The first three are the Core Web Vitals. FCP and TTFB are there as extras because they help explain a slow LCP. They don’t count toward the grade.

How the report is built

We follow redirects to the final address, then query CrUX twice, once for phones and once for desktops. Each query tries the exact page first and falls back to the whole origin when the page by itself has too little traffic. The line above each table says which one you’re reading.

The value shown for a metric is its 75th percentile, meaning three visits out of four were at least that fast. The colored bar beside it gives the share of visits in the good, needs-work and poor ranges.

For the grade, each Core Web Vital earns 2 points when good, 1 when it needs work and 0 when poor. Six points out of six is an A, five a B, four a C, three a D, two an E, and fewer an F. One poor metric caps the grade at D, however good the other two are. The headline grade is the phone grade when phone data exists.

When Chrome has no data

CrUX only covers pages that are public and visited often enough. For everything else, the report runs one PageSpeed Insights test on a simulated phone and tells you clearly that it did. You then get the Lighthouse performance score (A from 90, B from 75, C from 50, D from 35, E from 20), lab values for LCP and CLS, and Total Blocking Time in place of INP, since you can’t measure responsiveness to input without a person doing the input. Up to five audits with the largest estimated time savings are listed below.

What moves each number

LCP

Find the LCP element in the Performance panel of Chrome DevTools. It’s usually the main image. Serve it at its displayed size in WebP or AVIF, add fetchpriority="high", and never put loading="lazy" on it. If TTFB is already above 0.8 s, fix the server first with page caching or a CDN. The page size breakdown shows the heaviest files.

INP

Long JavaScript tasks keep the page from responding to input. Remove the tags and plugins you no longer use, load third-party scripts with defer, and split work that runs for more than 50 ms.

CLS

Give every image and video width and height attributes, reserve room for ads and embeds with min-height or aspect-ratio, and don’t insert banners above content that’s already visible.

Field data is a 28-day rolling window. After a fix, the figures get a little better every day and take four weeks to show the full effect. Visits from Safari and from any browser on an iPhone are never part of CrUX, so the report only describes your Chrome audience.