Field Data vs Lab Data: Why Your Lighthouse Score Disagrees with Search Console
## The short answer
If Lighthouse says your page is fast but Search Console reports failing Core Web Vitals, the explanation is almost always the difference between **lab data** and **field data**. Lab data is a single simulated test from a controlled environment; field data is collected from real Chrome users on real devices and connections over a 28-day window. Google ranks on field data, so when the two disagree, the field data is the one that counts. Lab data is for diagnosis, not for grading.
## What lab data is
Lab data comes from tools like Lighthouse and the lab section of PageSpeed Insights. It runs your page once, in a controlled setup — a specific simulated device, a throttled but consistent network, and a clean browser with no extensions or cached state. Its great strength is reproducibility: you can change something, re-run, and see whether the number moved.
Lab data is ideal for:
- Debugging a specific page during development
- Comparing two versions of a page in a controlled way
- Catching regressions in a build pipeline
Note that Lighthouse does not even report INP as a scored metric in the same way, because INP fundamentally depends on real user interactions that a single automated run cannot reproduce.
## What field data is
Field data — also called Real User Monitoring — comes from the **Chrome User Experience Report (CrUX)**, which aggregates anonymised measurements from real Chrome users who opt in to sharing usage statistics. This is the data behind the Core Web Vitals report in Search Console and the "field" section of PageSpeed Insights.
Field data reflects the messy reality your lab cannot:
- A spread of devices, from flagship phones to ageing budget handsets
- Real networks, including poor mobile connections
- Cached versus first visits
- Real interaction patterns that drive INP
## Why the two diverge
There are several common reasons your clean Lighthouse run disagrees with the field:
1. **Device and network mix.** Your test machine is faster than the median real device.
2. **The 75th percentile.** Field data grades you on the experience of the slower 25% of visitors, not the median.
3. **Real interactions.** INP only shows up properly in the field because it depends on actual taps and clicks.
4. **Geography and caching.** Real users hit your site from many locations and cache states a single lab run never reproduces.
5. **Time lag.** Field data is a rolling 28-day window, so recent fixes take weeks to fully appear.
## Which one should you trust?
Use them for different jobs:
- **For ranking and reality:** trust field data. It is what Google uses and what your users actually experience.
- **For diagnosis and iteration:** use lab data. It tells you *why* something is slow and lets you test fixes quickly.
The correct workflow is to diagnose with lab data, ship a change, and then *confirm the win in field data* over the following weeks. Declaring victory on a lab score alone is the classic mistake.
## A reality check on data availability
Field data has a catch: it requires enough real traffic to be statistically meaningful. Low-traffic pages may have no field data at all, or only origin-level data rather than page-level. In those cases lab data is your only signal, but recognise that you are flying partially blind and should be conservative about assuming the field matches.
## Building a proper measurement loop
Serious teams do not rely solely on CrUX, because it is aggregated, sampled and delayed. They add their own Real User Monitoring using the web-vitals JavaScript library to capture every visitor's LCP, INP and CLS, then segment by device, page template and country. This reveals which segments are failing far faster and in more detail than Search Console alone. Standing up that monitoring reliably across a large site is genuinely hard, which is why purpose-built, enterprise-grade products exist in this space — the kind neart.ai builds.
## Practical takeaway
When Lighthouse and Search Console disagree, believe Search Console — it reflects real users at the 75th percentile, which is what Google ranks on. Use lab data to diagnose and to validate fixes quickly, then wait for the 28-day field window to confirm the improvement. And if you can, add your own real-user monitoring so you are not waiting weeks to learn whether a change actually worked.