No. Lighthouse is a lab-based diagnostic tool that measures synthetic performance under controlled, simulated conditions, and Google’s actual ranking input for Core Web Vitals comes from real-user field data collected through the Chrome UX Report (CrUX), not from Lighthouse scores. Chasing a specific Lighthouse number as an SEO target confuses a debugging tool with the ranking-relevant measurement system, and the two can genuinely disagree: a page can score 100 in Lighthouse and still fail real-world Core Web Vitals thresholds, and a page can score poorly in Lighthouse while passing real-world field data thresholds comfortably.
The mechanism: lab data versus field data are different measurement systems
Google’s own documentation is explicit about this distinction, and it draws the line in two categories: lab data and field data. Lab data, what Lighthouse produces, is generated by loading a page in a controlled, simulated environment: a fixed, standardized network throttling profile, a fixed device emulation profile, a single run (or a small number of runs) at a specific moment in time. It’s useful precisely because it’s controlled and reproducible, which makes it excellent for debugging a specific performance issue and testing whether a specific fix actually helped, since the same conditions produce comparable before/after results.
Field data, what CrUX collects and what actually feeds Core Web Vitals assessment for ranking purposes, is aggregated from real Chrome users, on their actual devices, over their actual network conditions, across many real page loads over a rolling time window. This is fundamentally a different kind of measurement: it captures the messy diversity of real-world conditions, someone on a fast fiber connection with a high-end phone, someone on a congested mobile network with an older device, both contributing data points to the same URL’s real-world performance profile.
These two data sources can diverge significantly. A developer testing locally or in a lab environment with a fast connection and no real-world network variance might see excellent Lighthouse scores, while the actual distribution of real users, many on slower connections, older devices, or in regions with worse network infrastructure, experiences meaningfully worse load times that never show up in the lab test. Conversely, a page might have a mediocre Lighthouse score due to a specific lab-environment quirk (a particular third-party script behaving poorly under Lighthouse’s throttling profile, for instance) while real users, often on faster connections or benefiting from caching that the lab test doesn’t replicate, actually have a perfectly acceptable experience reflected in CrUX field data.
Google’s PageSpeed Insights tool displays both data sets side by side specifically because they serve different purposes, but only the field data section is described as reflecting the same real-user metrics that feed into page experience and Core Web Vitals assessment used for ranking-relevant evaluation.
Why “90+ Lighthouse” as a target is the wrong optimization goal
Treating a Lighthouse score threshold as an SEO target conflates a debugging metric with a ranking metric. A team could invest significant engineering effort chasing Lighthouse score improvements, adjusting things that move the lab score under Lighthouse’s specific simulated conditions, without moving the real-user Core Web Vitals numbers that actually matter for page experience assessment, if those efforts don’t address what real users on real devices and networks are actually experiencing. It’s also possible to over-index on a Lighthouse number as a vanity metric for internal reporting while genuine field performance for the actual audience stays unaddressed.
This isn’t an argument that Lighthouse scores are meaningless, they’re a legitimate and valuable diagnostic tool. Lighthouse is excellent at pinpointing specific technical causes: exactly which resource is blocking render, exactly which image is oversized, exactly which script is causing layout shift. That diagnostic precision is exactly why it remains useful, just not as the metric to report against as an SEO KPI.
Why teams gravitate toward the Lighthouse number anyway
There’s a practical reason “get Lighthouse to 90+” persists as an informal target despite this distinction being well documented: Lighthouse produces an immediate, easily-communicated single number on demand, runnable locally or in CI on every commit, while CrUX field data has an inherent reporting lag (it reflects a rolling window of real-user traffic over the past 28 days in its most common public form) and requires the page to have actually accumulated real traffic first. For engineering teams wanting a fast feedback loop to validate a change before it ships, Lighthouse is genuinely the more practical tool to check against in the moment, the mistake isn’t using Lighthouse for that purpose, it’s treating that same convenient number as the actual SEO-relevant KPI to report externally or to leadership, when the dataset that genuinely feeds page experience assessment is the slower-moving, traffic-dependent field data instead.
A reasonable practical split is using Lighthouse (or the similar lab-based tooling built into CI pipelines) as a pre-deployment gate, catching regressions before they ship, real-time, reproducible, useful for engineering workflow, while treating CrUX/field data as the actual reporting and prioritization metric for what’s genuinely affecting the site’s real users and, by extension, ranking-relevant assessment, checked on a slower cadence appropriate to its own data-refresh window.
Practical implication
Use Lighthouse for what it’s built for: identifying and debugging specific technical performance issues, gating regressions in CI before they ship, and validating that a fix actually worked in a controlled, repeatable test environment. Use CrUX field data, accessible through PageSpeed Insights’ field data section, the Search Console Core Web Vitals report, or the public CrUX dataset/API, as the actual measurement of record for page experience and Core Web Vitals status, since that’s the dataset genuinely tied to ranking-relevant assessment. If Lighthouse and field data disagree, trust field data as the picture of what real users, and by extension Google’s ranking systems, are actually seeing, and use Lighthouse to help figure out why the discrepancy exists rather than treating the lab score itself as the goal.
