CrUX vs Lighthouse: Why Your Two Scores Disagree

What exactly is each tool measuring?

The two answer different questions. Lighthouse answers "what happens when this page loads under these conditions?" CrUX answers "what has been happening to the people who actually visit?"

	Lighthouse (lab)	CrUX (field)
Data source	One simulated load on one machine	Aggregated real Chrome users
Conditions	Fixed, throttled CPU and network	Whatever your audience actually has
Window	This instant	Rolling 28 days
Reported as	A 0–100 score plus metrics	Metric distributions at the 75th percentile
Interaction metrics	Estimated (Total Blocking Time)	Measured (INP from real interactions)
Availability	Any URL, always	Only pages with enough traffic
Used for ranking	No	Yes
Best for	Diagnosing causes	Confirming reality

The row that trips people up most is the interaction one. Lighthouse cannot measure INP, because nobody is clicking anything during an automated load — so it reports Total Blocking Time as a proxy. A page can post an excellent TBT and still deliver a poor INP in the field, because the expensive work happens on a menu tap the lab run never performed.

How does CrUX actually collect its data?

Understanding the eligibility rules explains most confusing CrUX results, and Google publishes them in the CrUX methodology documentation.

A page or origin qualifies only if it meets two conditions:

1. Publicly discoverable. It must meet ordinary indexability standards. Pages that return a non-200 status, carry an X-Robots-Tag: noindex header, or include a noindex robots meta tag are excluded.
2. Sufficiently popular. Google requires "a minimum number of visitors" and deliberately does not publish the threshold. The point is statistical confidence — a distribution built from a handful of visits would be noise.

The user side has its own filter. A Chrome user contributes data only if they have enabled usage statistic reporting, are syncing browser history, are not using a sync passphrase, and are on a supported platform.

That last condition excludes more than people realise:

• Chrome on iOS does not contribute. On iOS, Chrome is a wrapper around WebKit, so its performance characteristics are not Chrome's.
• Android WebView traffic does not contribute — including in-app browsers, which is where a large share of social referral traffic lands.
• Other Chromium browsers do not contribute. Edge, Brave, Opera and Arc users are invisible to CrUX.
• Firefox and Safari do not contribute, on any platform.

So CrUX is not "all your users." It is the Chrome-on-desktop-and-Android, opted-in subset of them — a large and representative slice for most sites, but one worth remembering before you treat it as a census.

Two more mechanics matter for reading the data honestly: query parameters and fragments are stripped, so /article?utm_source=x and /article are grouped together; and the data is fuzzed and filtered for privacy, so very precise readings are not meaningful.

Why the 28-day window and the 75th percentile matter

Both choices have practical consequences that catch people out.

The 28-day rolling window means the data lags. Ship a fix today and CrUX will not fully reflect it for four weeks — each day the oldest day drops off and a new one enters, so you see a gradual slide rather than a step change. Teams routinely conclude a fix "did nothing" when they check three days later. It is also why a bad week can keep depressing your numbers well after the cause is gone.

The 75th percentile means you are being judged on your slower visits. A metric is "good" only if at least 75% of measured visits met the threshold. The median user's experience is not the standard; the experience at the three-quarter mark is. The current thresholds:

Metric	Good	Needs improvement	Poor
LCP	≤ 2.5 s	2.5–4.0 s	> 4.0 s
INP	≤ 200 ms	200–500 ms	> 500 ms
CLS	≤ 0.1	0.1–0.25	> 0.25

This is also why aggregate improvements can feel invisible. Making fast visits faster moves the median and does nothing for the 75th percentile. Making slow visits less slow is the work that moves the assessment — which usually means low-end Android devices, poor connections, and cold caches rather than your development machine.

Why the two scores legitimately disagree

Most divergence has an ordinary explanation. Working through them in order will resolve nearly every case.

Lighthouse is green, CrUX is red. Your test conditions are kinder than your audience's. You tested on a fast laptop over office broadband; a meaningful share of real visits arrive on mid-range phones over mobile networks. Also check whether the lab run is missing real-page behaviour — consent banners, personalisation, logged-in states, ad and analytics scripts that only fire in production.

Lighthouse is red, CrUX is green. Usually the simulated throttling is harsher than reality, or the lab run tripped over something transient. If real users are fine, they are fine — but treat the Lighthouse output as a list of latent risks rather than a false alarm.

CrUX shows nothing at all. The URL has not met the popularity threshold. PageSpeed Insights will often fall back to origin-level data, so check whether the field section is describing this page or the whole site before drawing conclusions from it.

The URL-level and origin-level numbers differ sharply. Entirely normal. Your article template and your homepage are different pages with different weights; origin-level data is an average across everything, dominated by whichever templates get the most traffic.

Which tools should you actually use?

Use them in this order, because each answers a different question.

1. Search Console's Core Web Vitals report — the site-wide view of field data, grouped into URL sets with similar behaviour. Start here: it tells you which templates have a problem, which is the only question worth asking first.
2. PageSpeed Insights — both datasets for one URL side by side. The fastest way to see field and lab for the same page.
3. The CrUX API and CrUX History API — programmatic access to current and historical field data, which is what you want for a dashboard or a regression check in CI.
4. CrUX on BigQuery — the full monthly dataset, useful for competitive benchmarking. Note the cadence: it is monthly, released on the second Tuesday after the collection period, so it is the slowest of the four to reflect a change.
5. Lighthouse locally or in CI — for diagnosis and for catching regressions before they ship. This is where lab data genuinely shines: it is reproducible, which field data never is.

The pattern that works: Lighthouse and lab tooling tell you what to fix; CrUX tells you whether fixing it mattered. Neither replaces the other, and a team using only one of them is either optimising for a machine nobody uses or flying blind on causes.

The mistake worth avoiding

Do not chase a Lighthouse score of 100. It is a composite of weighted lab metrics, it is sensitive to conditions on the machine running it, and it is not what Google ranks on. Past a certain point, further gains cost real engineering time and change nothing for real users or for search.

The corollary is more uncomfortable: a site can have perfect lab scores and genuinely poor real-world performance, and the lab score will never tell you. That is the entire reason the field dataset exists. If you only ever look at one number, look at the field one — and if you have no field data yet, that is itself worth knowing, because it means you are optimising ahead of having an audience to optimise for.

For what these metrics mean individually and how to fix each one, start with Core Web Vitals explained.

Sources: Chrome for Developers — CrUX methodology · Chrome for Developers — CrUX overview · Chrome for Developers — CrUX API · Chrome for Developers — CrUX on BigQuery