You run Lighthouse and get a green performance score. Then you open PageSpeed Insights and the Core Web Vitals assessment says your page needs improvement.
Or the opposite happens: Lighthouse reports a slow page, while real-user data looks healthy.
Nothing is necessarily broken. The two results answer different questions.
Lighthouse gives you lab data from one controlled test. Chrome UX Report, usually called CrUX, gives you field data collected from real Chrome users. Understanding that difference can save hours of debugging the wrong problem.
Lab data: a controlled experiment
Lighthouse loads a page using predefined device and network conditions. A typical mobile run applies CPU and network throttling and usually behaves like a new visitor with a cold cache.
This makes Lighthouse useful because the test can be repeated. You can change your code, run it again, and compare the results under similar conditions.
Lighthouse is particularly useful for:
- finding render-blocking resources
- identifying large images or JavaScript bundles
- diagnosing main-thread work
- detecting layout shifts during the initial load
- catching performance regressions before deployment
But a Lighthouse result is still one test from one environment. It is not a survey of every person visiting your website.
Field data: what real users experienced
CrUX collects performance measurements from eligible real Chrome users. PageSpeed Insights uses this dataset in its field-data section.
Instead of testing one simulated device, field data includes a distribution of real visits across different:
- phones and computers
- network speeds
- locations
- cache states
- browsing sessions
- user behaviours
CrUX generally reports a rolling 28-day view and evaluates Core Web Vitals at the 75th percentile. In simple terms, the reported value is intended to represent an experience that at least 75% of visits met or beat.
This makes field data the better answer to: “What experience are our users actually getting?”
Why the numbers disagree
1. The tested device is not your users' devices
A Lighthouse mobile test simulates a particular level of CPU and network performance. Your visitors may use faster devices, slower devices, or a completely different mix.
One lab run cannot reproduce that entire distribution.
2. Lighthouse often tests a cold load
A lab test commonly loads the page without the benefit of previously cached assets. Returning users may already have fonts, scripts and images cached.
This can make Lighthouse look worse than field data. The reverse can happen when real users face slow networks, overloaded devices or third-party content that did not appear in the lab run.
3. Real users interact with the page
A default Lighthouse audit focuses heavily on the initial page load. Real visitors scroll, open menus, accept cookie banners, load more content and use interactive components.
This difference is especially important for CLS and INP.
A page may have no obvious layout shift during loading but shift later when a lazy-loaded component, advertisement or embedded widget appears. CrUX can capture that real experience even when a basic Lighthouse run does not.
Similarly, Interaction to Next Paint depends on actual interactions. A load-only test cannot reproduce every slow click, tap or keyboard action your users encounter.
4. You may be comparing a URL with an entire origin
PageSpeed Insights shows URL-level field data when enough data is available. When it is not, it may fall back to origin-level data.
That means you could accidentally compare:
- Lighthouse data for one specific page
- CrUX data representing many pages across the domain
Always check whether the field section says “This URL” or “Origin” before investigating a mismatch.
5. Field data is historical; Lighthouse is happening now
Lighthouse tests the current version of the page. CrUX uses a rolling window of recent user experiences.
After deploying a performance improvement, your Lighthouse result can improve immediately while CrUX changes gradually as new visits replace older data.
6. The page is not identical for every visitor
A/B tests, ads, consent banners, personalisation, authentication state and third-party scripts can change what gets loaded.
Lighthouse may see one version while different groups of users see something else. Even repeated Lighthouse runs can fluctuate when the page or underlying conditions change.
Which result should you trust?
Trust field data when judging the experience your real users receive and whether your site meets Core Web Vitals in practice.
Use Lighthouse to diagnose problems, reproduce controlled scenarios and prevent new regressions.
It is not field data versus Lighthouse. A useful workflow needs both:
- Field data tells you that a real problem exists and how widespread it may be.
- Lab data helps you understand, reproduce and fix specific causes.
The overall Lighthouse performance score is also not the same thing as the Core Web Vitals assessment. Compare the individual metrics—LCP, INP and CLS—rather than expecting the two headline results to match.
A practical debugging workflow
Step 1: Read the field-data label
In PageSpeed Insights, confirm whether the CrUX result represents the exact URL or the whole origin.
Step 2: Compare individual metrics
Identify whether the disagreement is mainly in LCP, INP or CLS. Each metric points toward different causes.
Step 3: Re-run Lighthouse consistently
Use the same test mode, device category and environment. Run it more than once and look for a pattern instead of treating one score as absolute truth.
Step 4: Investigate what the lab test misses
If field data is worse, examine real user journeys:
- scroll through the full page
- interact with menus and forms
- test consent banners and embedded widgets
- check slower devices and networks
- investigate post-load layout shifts
- collect your own Real User Monitoring data when possible
The web-vitals JavaScript library can help collect field measurements and attribution information from your own users.
Step 5: Use Lighthouse diagnostics to fix reproducible causes
If the lab and field metrics point in the same direction, Lighthouse audits can help locate heavy resources, long tasks, delayed content and layout-shift culprits.
Step 6: Monitor after deployment
Confirm the immediate improvement in a controlled test, then watch field data over time. CrUX will not fully reflect a deployment immediately because its reporting window includes earlier visits.
A simple way to remember it
Lighthouse is a crash test performed under controlled conditions.
CrUX is information collected from cars being driven by real people on real roads.
The crash test helps engineers find weaknesses. The road data shows what drivers actually experience. You need both to build something reliable.
The next time Lighthouse and Core Web Vitals disagree, do not ask which tool is wrong. Ask what population, time window, device conditions and user journey each result represents.
Sources:
Top comments (0)