Guides

You run Lighthouse, you get 100, you ship. A month later Search Console tells you the same URL fails its Core Web Vitals assessment. Nothing broke in between, and neither tool is lying. They are answering different questions.

Google's own documentation draws the line clearly. Lab data is **"data collected in a controlled environment with predefined device and network settings"**. Field data is **"data collected from the real users visiting your site"**, also called Real User Monitoring, and for Core Web Vitals it comes from the Chrome User Experience Report.

Field data is a distribution, not a number

The most important consequence is structural, and it is the part most people miss: field data **is not a single number**. It is a distribution. Tools that report a Core Web Vitals field score take the **75th percentile** of real page loads over a rolling **28-day** period. Your lab run is one load, on one device, on one connection. Your field score is what three quarters of your visitors did or better, across a month.

That alone explains most of the gap. But the causes differ by metric, and knowing which one you are looking at tells you where to go looking.

Why they diverge, metric by metric

For [Largest Contentful Paint](/articles/what-is-largest-contentful-paint-lcp), the LCP element itself may not be the same one. Viewport size, personalised content, A/B tests, installed fonts and URL fragments can all change which element counts as largest. Cache state differs too: a lab test starts cold, while returning visitors may have resources cached. And restoration from the back/forward cache is near instantaneous for real users, something no lab run reproduces.

• Lab: controlled environment, predefined device and network, one run, reproducible
• Field: real users, real devices, real connections, reported at the 75th percentile over 28 rolling days
• Lab-only metrics: Speed Index, Total Blocking Time (diagnostics, not Core Web Vitals)
• Cache state, back/forward cache, viewport and personalisation all differ between the two
• Google: with both available, prioritise on field data

For [Interaction to Next Paint](/articles/what-is-inp-interaction-to-next-paint), the reason is more fundamental: a lab test **cannot know when a user will choose to interact**, or with what. That is why [Total Blocking Time](/articles/what-is-total-blocking-time) exists as its lab-side proxy, and also why the proxy is imperfect. TBT does not capture the 300 ms tap delay that still affects pages without a mobile-optimised viewport.

For [Cumulative Layout Shift](/articles/what-is-cls), the lab typically only observes shifts above the fold and during load. Real users scroll. Lazy-loaded images and iframes without reserved dimensions shift the page long after the lab test has stopped watching, and ads and personalised blocks land differently for everyone.

Which one Google actually reports

So which one should you act on? Google states the answer plainly: **if you have both, field data is what you should use to prioritise your efforts.** Field data is what the Core Web Vitals assessment reports, and Core Web Vitals are part of the page experience signal. A green lab score is a hypothesis. Field data is the verdict.

The lab is not useless, it is diagnostic

That does not make the lab useless, and treating it as useless is the opposite mistake. Field data tells you **that** something is wrong and for whom; it will not tell you which script blocked the main thread. Lab tools are reproducible and attributable, which is exactly what you need once the field has pointed you at a page. Some metrics, including [Speed Index](/articles/what-is-speed-index) and Total Blocking Time, exist only in the lab and are diagnostics by design.

The blind spot: when CrUX has nothing on you

One limit is worth knowing before you lean on the field entirely. CrUX collects only from Chrome, and not from Chrome on iOS or Android WebView. It counts only users who have enabled usage statistics reporting, sync their browsing history and have no sync passphrase set. The page must be publicly discoverable, and it must clear a minimum visitor count that Google deliberately does not publish. A page below that bar simply has no field data, and a young or low-traffic site may have none anywhere. That is the gap your own Real User Monitoring fills: your pages, every browser, from the first visit rather than from the thousandth.

The order that works

The practical order is therefore: read the field to decide **where** to work, then use the lab to find out **what** to change, then go back to the field twenty-eight days later to confirm it actually moved. Anything else is optimising a number nobody experiences. If you want the concrete levers once you know where to dig, start with [improving your Core Web Vitals](/articles/improve-core-web-vitals).