A strong Lighthouse score and poor real-user performance can both be accurate.
They describe different things. Lighthouse measures one controlled page load under a defined set of conditions. Core Web Vitals field data describes what a population of real visitors experienced across different devices, networks, locations, and visits.
The useful question is not which number is lying. It is which dataset answers the question you are trying to solve.
Lighthouse is lab data; CrUX is field data
| Lighthouse | Chrome UX Report (CrUX) | |
|---|---|---|
| Data source | A synthetic page load | Eligible real Chrome visits |
| Conditions | Controlled device and network simulation | Real devices, networks, caches, and locations |
| Best use | Diagnosis, development, and regression checks | Measuring real-world experience over time |
| Update speed | Immediate | Daily data over a rolling 28-day collection span |
| Interaction measurement | Uses lab diagnostics such as TBT | Includes real Interaction to Next Paint data |
Google’s own Core Web Vitals workflow describes Lighthouse as a lab diagnostic and CrUX as field data. Neither replaces the other.
Why the numbers diverge
Lighthouse samples one set of conditions
A Lighthouse run represents a single load with simulated network and CPU constraints. Change the test device, throttling, location, server response time, or extension state and the result can move.
That consistency is useful when comparing one build against another. It is not a representative sample of everyone who visits the site.
Real visitors carry history
Some visitors arrive with cached fonts and scripts. Others are seeing the site for the first time. A returning user may have a service worker, consent choice, or authenticated layout that Lighthouse never sees.
Third-party scripts also behave differently in production. An analytics provider that responds immediately in one test can take several seconds for a user on a congested mobile connection.
CrUX is aggregated
The CrUX API reports a rolling 28-day view. A regression deployed yesterday may barely move the field result, while a problem fixed yesterday can remain visible for weeks.
CrUX can also report page-level or origin-level data. When a URL lacks enough eligible traffic, PageSpeed Insights may show origin data instead. Always check which scope and device class you are reading before comparing numbers.
INP needs actual interaction
Interaction to Next Paint measures how a page responds when a person interacts with it. A synthetic page load without a user cannot reproduce the full distribution of real interactions. Lighthouse uses diagnostics such as Total Blocking Time to expose related main-thread problems, but TBT and INP are not interchangeable.
A practical workflow that uses both
1. Start with field data
Check PageSpeed Insights or Search Console for LCP, INP, and CLS at the 75th percentile. Segment mobile and desktop. Confirm whether the result is for the exact URL or the whole origin.
The current Core Web Vitals thresholds and measurement guidance are maintained in Google’s Web Vitals documentation.
2. Reproduce the problem in a lab
Run Lighthouse several times against the production page, not a development server. Keep the device and throttling settings consistent. A median of three to five runs is more useful than the most flattering result.
Then inspect the audit details rather than the score:
- What was the LCP element?
- Which requests blocked its render?
- Did a font or client-side script delay visible text?
- Which long tasks occupied the main thread?
- Did an image or dynamic component cause layout movement?
If a field regression appeared after a deploy, follow the ordered process in How to debug a Core Web Vitals regression.
3. Make one measurable change
Fix the resource or behavior connected to the metric. Examples include prioritizing the real hero image, removing a render-blocking request, reserving image dimensions, or breaking a long interaction task into smaller work.
Re-run the same Lighthouse setup. The lab result should improve for a reason you can explain, not because the score happened to fluctuate.
4. Monitor the field result
Ship the change and watch your own Real User Monitoring if you have it. CrUX will reflect the change gradually because of its rolling collection window.
SiteCMD’s live-site checks keep the deterministic parts of this workflow in one place: headers, assets, page structure, metadata, and performance signals that can regress between releases.
What if the site has no CrUX data?
Low-traffic and new sites may not meet CrUX eligibility thresholds. That does not mean performance is unknowable.
Use Lighthouse as a controlled regression tool and collect your own field measurements with the web-vitals library or a RUM provider. Record the page, device class, release, and metric values so you can compare distributions instead of isolated anecdotes.
Until enough field data exists, a repeatable lab setup plus a strict performance budget is much better than chasing a perfect score.
The right mental model
Use field data to decide whether users have a problem. Use lab tools to understand why the problem exists and whether a proposed fix improves the controlled case.
Lighthouse is a debugger and regression signal. Core Web Vitals field data is the user-experience outcome. The most reliable performance process keeps both, labels them clearly, and never turns either one into a vanity number.