Field data is performance measured on real visits to your site, by real browsers, on the devices and connections your visitors actually have. Lab data is one page load performed on purpose, by a tool, under fixed conditions. PageSpeed Insights shows you both on the same screen, they routinely disagree, and almost every argument about whether a site “is fast” turns out to be an argument about which of the two someone is looking at.
How the field number is assembled
Google’s field source is the Chrome User Experience Report, collected from Chrome users who have opted in to reporting. Three properties of it explain most of the confusion:
- It is the 75th percentile, not an average. Three visits in four must be at or under the figure. One slow quarter of your audience is enough to fail, which is the point: averages hide exactly the visitors you are losing.
- It is a rolling 28-day window. Fix something today and the reported number moves for a month afterwards, arriving gradually instead of on the day of the deploy.
- It needs traffic. A page without enough visits has no page-level data, and the report falls back to an origin-level figure for the whole site. A quiet page can be graded on its noisy neighbours.
Lab data has none of those properties, and that is its use: it is reproducible, available instantly, available for a page nobody has visited yet, and it points at a cause rather than a symptom.
Everything on this site is lab data
We should state that plainly instead of letting it be inferred. Every number we publish, on every audit page, research study and platform page, comes from a Lighthouse run: a simulated mid-tier phone on a throttled connection, loading the page once, never scrolling, never tapping. We have no field data for the sites we audit, because field data belongs to whoever owns the property, and we are measuring other people’s pages from the outside.
That makes the translation question a live one for us, and the three Core Web Vitals do not translate equally:
| Vital | Survives the lab? |
|---|---|
| LCP | Well. The run genuinely watches the largest element paint, and the causes it finds are the ones real visitors meet. |
| CLS | Badly, and in the direction that hides defects. |
| INP | Not at all. It needs an interaction the lab never performs. |
The CLS gap, with a number on it
The middle row is not a caveat we inherited from documentation, it is something we measured. Of 162 sites we parsed, 86 ship at least one image with no dimensions. 82 of those 86 still score “good” on lab CLS, and 26 score exactly zero. The lab run never scrolls, most unsized images sit below the fold, and a shift that happens during a scroll nobody performs is a shift nobody records.
Google documents the mechanism directly: lab CLS “only considers layout shifts that occur above the fold and during load”, while the field metric counts them “throughout the lifespan of the page, including content that shifts as the user scrolls.”
When the two disagree, who wins
Treat lab data as the diagnostic and field data as the verdict. The lab tells you what to change and lets you verify the change immediately; the field tells you whether it reached anyone. A page can score 95 in a lab run and fail its Core Web Vitals assessment, or pass in the field while scoring poorly in a lab run on hardware nobody in your audience uses.
The failure mode worth naming is optimising for the lab specifically. Tools that defer all JavaScript until a user interaction improve every lab metric precisely because the lab never interacts. The work is not removed, it is moved onto the first person who touches the screen, and INP is the only metric that sees the bill.
Getting field data for your own site
- Search Console, Core Web Vitals report. Free, grouped by URL pattern, the same CrUX source Google grades you on.
- PageSpeed Insights, the upper half of the report, when the page has enough traffic.
- The
web-vitalslibrary, if you want per-page numbers on your own analytics and do not want to wait 28 days to learn whether a deploy helped.
What our audit can and cannot tell you
An audit here shows you the before and after of one simulated load, itemised down to which optimisation produced which change. That is a real answer to “what is slow and what would fix it”, and it is not an answer to “what are my visitors experiencing”. For the second question the data already exists, it is in your Search Console, and it is worth opening alongside anything we hand you.