Core Web Vitals vs Lighthouse: Field Data, Lab Data, and Which One Google Actually Ranks On

The single most common confusion in web performance is a page that scores 95 in Lighthouse and shows "Core Web Vitals assessment: Failed" at the top of the same PageSpeed Insights report. People assume one of the numbers is wrong. Neither is. They measure different things, from different sources, for different purposes, and only one of them is a ranking input. Once you know which is which, the report reads completely differently.

Two sources of data on one page

Open PageSpeed Insights for any URL with meaningful traffic and the report has two halves.

The top half is field data. It comes from the Chrome User Experience Report (CrUX), which aggregates real page loads by real Chrome users who have opted into usage statistics. It is reported as the 75th percentile of those users' experiences over the trailing 28 days. If the page had enough eligible traffic, you see a verdict — passed or failed — and a distribution bar for each metric. If it did not, you see "no data", and the report may fall back to origin-level numbers for the whole site.

The bottom half is lab data. It comes from Lighthouse, which loads the page once, right now, on a simulated device (a mid-range Android phone on a throttled 4G connection, by default), and measures what it observed. The performance score, the numbered opportunities ("Eliminate render-blocking resources"), the filmstrip: all of that is one synthetic run.

The two halves disagree constantly, and there are structural reasons why.

	Field (CrUX)	Lab (Lighthouse)
Who	Real Chrome users, 28-day window	One simulated load
Device	Whatever your users actually have	One throttled profile
Network	Whatever your users actually have	Simulated slow 4G
Cache	Mixed: many repeat visitors have warm caches	Cold, always
Interaction	Real clicks, taps, scrolls	None (INP cannot be measured)
Reported as	p75 across users	A single run's values
Used for ranking	Yes (the three Core Web Vitals)	No
Available for	Pages with enough traffic	Any URL, instantly

The last two rows are the important ones. Google's page experience signal uses field data. Lighthouse scores are a diagnostic tool Google publishes; they are not collected from your site and they are not a ranking factor. A page can have a Lighthouse score of 40 and pass Core Web Vitals in the field, and vice versa, and only the field result affects ranking.

The three Core Web Vitals and their thresholds

Core Web Vitals are three specific field metrics with fixed thresholds. A page "passes" when its p75 is under the "good" threshold on all three.

Metric	Measures	Good	Poor
LCP — Largest Contentful Paint	Time until the largest visible element (usually the hero image or the headline block) has rendered	≤ 2.5 s	> 4.0 s
INP — Interaction to Next Paint	Worst-case latency from a user interaction (click, tap, key) to the next frame painting, across the whole visit	≤ 200 ms	> 500 ms
CLS — Cumulative Layout Shift	How much visible content moved around unexpectedly, summed over the largest burst of shifts	≤ 0.1	> 0.25

Between good and poor is "needs improvement", which counts as not passing.

Three things about these that are regularly misreported:

INP replaced FID in March 2024. First Input Delay measured only the delay before the first interaction's handler started running. INP measures the full latency of interactions across the entire visit and takes a high percentile. Any article still talking about FID predates the change. Pages that passed FID trivially, because the first tap happened before any heavy JavaScript ran, routinely fail INP, because the tenth tap hit a 600 ms React re-render.

The 75th percentile is the number. Not the average, not the median. If 74% of your users see LCP at 1.8 s and 26% see it at 5 s, your p75 is somewhere around 4 s and you fail. This is why field data is so much harsher than lab data for sites with a long tail of slow devices or slow regions: the lab measures one device; the field measures your worst quarter.

The assessment is per URL when there is enough data, and per origin when there is not. A brand-new page shows origin-level numbers. That means a blog post you published yesterday inherits the site's overall vitals, good or bad, until it accumulates its own sample. It also means fixing one heavy template can move the origin number, which then applies to every thin-traffic page on the site.

What Lighthouse is actually for

If Lighthouse does not affect ranking, why does every performance article lead with it?

Because it is the only tool that gives you a number immediately, for any URL, with a list of things to try. Field data tells you that LCP is 3.9 s for your users. It does not tell you why. Lighthouse loads the page and says: the LCP element is img.hero, it was discovered late because it is loaded by JavaScript, it is 1.4 MB, and it is behind two render-blocking stylesheets. That is actionable. The field number is the goal; the lab run is the debugger.

The way to use them together:

1. Read the field verdict first. That is the score that matters. If it passes, you are done with Core Web Vitals as a ranking concern, whatever Lighthouse says.
2. If a metric fails in the field, look at the same metric in the lab. If the lab reproduces the problem, the opportunities list will usually point at the cause.
3. If the lab does not reproduce it, the problem is something the lab cannot see: real users on slower devices than the simulation, a third-party script that only loads for certain regions or logged-in users, a warm-cache versus cold-cache difference, or, for INP specifically, interactions that a no-interaction lab run never triggers. Use the Chrome DevTools performance panel on a real device, or a RUM tool that records individual slow interactions.
4. Ignore the Lighthouse performance score as a target. It is a weighted blend of lab metrics with a scoring curve. Two pages with identical user experiences can differ by ten points because one loads a font slightly later. Chasing 100 is chasing the curve, not the users.

Why the two halves disagree, specifically

Some concrete cases, because "they measure different things" is true but does not help you debug.

Lighthouse good, field bad on LCP. Your users are on worse devices or connections than the simulation, or in regions far from your origin, or your CDN is not caching the HTML. Also common: an A/B testing or consent script that delays render for real users and is absent in the lab because it depends on a cookie.

Lighthouse bad, field good on LCP. Most of your traffic is repeat visitors with a warm cache, or desktop users, or you have a fast CDN and the lab's simulated throttling is harsher than anything your users actually experience. This is the "why is my score 60 when the site feels fast" case. It is fine. The field is what counts.

Field bad on INP with no lab equivalent. Lighthouse reports Total Blocking Time as a proxy for interactivity, but it cannot measure INP because it never interacts. A page with a heavy click handler, a slow route transition, or a large re-render on typing will fail INP in the field and show nothing alarming in the lab. This is the metric most sites fail today and the one the lab helps least with.

Field bad on CLS, lab fine. Layout shifts caused by things that happen late: a cookie banner that pushes content down after consent loads, an ad that loads after the lab run finished, an image without dimensions in a component that only renders for logged-in users. Field CLS covers the full session; the lab stops measuring shortly after load.

Checking a page

The tools, in order of how often you will use them:

PageSpeed Insights (the web UI or its API) gives you both halves for one URL. This is the daily driver. The Core Web Vitals check on this site's dashboard is a wrapper around the same API, and it keeps the two halves in separate panels on purpose, because the single most useful thing a tool can do here is refuse to blend them.

Search Console's Core Web Vitals report shows field data grouped by URL pattern across your whole site. This is where you find out that one template is dragging the origin down. It lags CrUX by a few days.

The CrUX dashboard or BigQuery dataset gives you the raw monthly field data, per origin, with device and connection breakdowns. Useful for the "which quarter of my users is slow" question.

Chrome DevTools performance panel on a real, cheap Android phone, plugged in. For INP there is no substitute.

What this means for priorities

• If your page fails a Core Web Vital in the field, that is a ranking-relevant problem, and Lighthouse is how you start diagnosing it.
• If your page passes in the field and scores 55 in Lighthouse, you have a good page and a low lab score. Spend the time elsewhere.
• If your page has no field data, you cannot pass or fail; the origin's numbers apply. Fix the templates that carry the origin's traffic.
• INP is the one to worry about on JavaScript-heavy sites. It is the one the lab cannot see and the one that was easiest to ignore under FID.

Page experience is a tie-breaker signal, not a primary one. A page that fails CWV with the best content still outranks a page that passes with worse content. But between comparable pages, and for the not-small number of sites where failing vitals coincide with a genuinely slow experience, it is worth passing, and the only way to know whether you do is the top half of the report. If you want the rest of the technical list this belongs to, the technical SEO checklist puts server response time and page weight in context with everything else, and Search Console versus SEO tools covers where the field data comes from and what GSC can and cannot tell you about it.