Field data, lab data, and why your speed scores disagree
A familiar scene: Lighthouse proudly reports a performance score in the nineties, while the Core Web Vitals report in Search Console marks the same pages as needing improvement. Someone asks which tool is lying. Neither is. They measure different things, under different conditions, for different purposes, and confusing them leads to optimizing the wrong number.
Two kinds of truth
Field data is what real visitors experienced. Chrome collects performance measurements from actual users who opted into reporting, aggregates them in the Chrome User Experience Report (CrUX), and evaluates each metric at the 75th percentile over a rolling 28-day window. This is the data behind the Core Web Vitals assessment in PageSpeed Insights and Search Console, and it is what Google's ranking systems reference. It reflects every real network, every mid-range phone, every distracted tap.
Lab data is a controlled experiment. Lighthouse loads the page once, on simulated hardware with simulated throttling, and reports what happened in that synthetic visit. It exists for debugging: it is reproducible, it works on pages with no traffic and on staging environments, and it produces detailed traces that field data cannot provide. The famous 0 to 100 performance score is a lab artifact. It is not a ranking factor, and no amount of chasing it changes what CrUX records.
Why they disagree
Divergence is not an anomaly; it is the expected result of different populations. A few patterns explain most of it.
Audience versus simulation. Lab throttling approximates a slow device and network. If real visitors are mostly on fast phones and good connections, field beats lab. If they skew toward older devices or weak mobile networks, field looks worse than any test run from an office.
Caching and journey. Lab tests a cold first view of one URL. Real users arrive with warm caches, or land on pages the lab never tested.
Interactions only happen in the field. INP needs real clicks and taps, so lab tools can only offer Total Blocking Time as a proxy. A page can load fast and still respond slowly when a real thumb arrives.
The 75th percentile. Field assessment is set by the slower quarter of visits. The median experience can be excellent while the assessment fails on the long tail.
Time windows. CrUX trails by up to 28 days, so a genuine fix shows in lab immediately and in field weeks later.
Using each for what it is for
The workflow that keeps teams sane runs in one direction: field decides what matters, lab explains why. Start in Search Console or the CrUX data in PageSpeed Insights and identify which metric fails, on which page groups, on which device type. Then reproduce the problem in the lab, with throttling that resembles the real audience, and use the traces to find the cause. Ship the fix, confirm it in the lab immediately, and wait out the field window for the assessment to move.
Sites with too little traffic for CrUX data get judged by no field assessment at all, and for them lab plus real user monitoring is the whole story. Everyone else should remember the hierarchy. The Lighthouse score is a helpful diagnostic and a terrible KPI. Real users are the exam; the lab is just where the studying happens.