Lab vs field: why the two disagree and how to use each

PageSpeed Insights shows LCP 1.8 s in the Lighthouse section — green, good. The field data section shows LCP 3.9 s at p75 — red, poor. The team says “the lab says we are fine.” They ship nothing. Three months later, Search Console still shows poor LCP. The lab score and the ranking are measuring different things. Knowing which one is the verdict changes everything.

Lab data vs field data — two different questions.

Lab data is a synthetic measurement: a tool like Lighthouse or DevTools loads the page once, on a simulated device and a throttled network, in a controlled environment. It is fully reproducible and it can attribute problems precisely — great for debugging. One device, one network, one moment. If you change the page and rerun, the result is comparable.

Field data is real-user monitoring: the actual Core Web Vitals experienced by real visitors on their real devices and networks, aggregated. Google’s public field dataset is CrUX — the Chrome User Experience Report. It aggregates visits from opted-in Chrome users, and the field p75 from CrUX is what Search ranking uses.

They disagree routinely because they measure different things. A lab run on a simulated fast device shows an LCP that a quarter of real users — on older phones, on congested 4G — never come close to. INP barely exists in the lab at all, because lab tools do not script realistic interaction sequences; the lab proxy is Total Blocking Time (TBT). CLS in the lab is close to real, but dynamic content that appears only with real user sessions can be missed.

The rule: debug in the lab, judge in the field.

Use the lab to reproduce and attribute a problem (fast, deterministic, easy to bisect commits), and to gate regressions in CI (Lighthouse CI runs on every PR, fast, no real users needed). Use the field p75 as the verdict on whether a page is actually good for users and whether it will rank. A lab improvement that does not move the field p75 did not help your users. Only the field number is the truth.

The supporting diagnostic metrics.

The three Core Web Vitals sit on top of a layer of diagnostic metrics that are not scored for ranking but are essential for understanding them:

• TTFB (Time to First Byte) — the server-and-network portion. It is the floor under LCP: LCP can never be faster than TTFB.
• FCP (First Contentful Paint) — when the first pixel of content appears, vs LCP’s largest. A large FCP-to-LCP gap means the page shows something quickly but the main content lags — a sign the LCP resource has load delay.
• TBT (Total Blocking Time) — the sum of the blocking portion of every long task during load. This is the lab proxy for INP: you cannot measure true INP in a lab (it needs real interactions), so CI gates use TBT instead. A high TBT predicts a high INP.

Knowing these is what lets you read a Lighthouse report fully — Lighthouse never just says “LCP is bad”, it shows TTFB and FCP so you can see where in the chain the time went.

Reading a DevTools performance trace.

Open DevTools, the Performance panel, record a page load and an interaction. The trace shows several tracks:

• Timings track: marks FCP, LCP, and DCL with vertical lines. Hovering the LCP marker names the exact element.
• Frames track: each rendered frame; layout shifts appear as red markers — click to see which nodes shifted.
• Main track: flame chart of main-thread work; long tasks are flagged with a red corner.
• Interactions track: click/tap events, broken into input delay, processing, and presentation delay — color-coded — so you can see which part dominates for each interaction without guessing.

The INP workflow: interact during the recording, find the interaction in the Interactions track, read the three-part split. The LCP workflow: find the LCP marker in the Timings track, hover to identify the element, then look at the network waterfall above it to see when the resource was requested vs when it downloaded vs when the element painted.