Run any page through Lighthouse — in Chrome DevTools, or through the PageSpeed Insights API — and you get a crisp number: a performance score out of 100, and Core Web Vitals like Largest Contentful Paint and Cumulative Layout Shift. It feels like the number. It's reproducible, it's precise, and it turns red or green on demand.
It is also a lab number: one synthetic run, on a simulated mid-range phone, with a fixed throttled network, from one location, on a cold cache. That is a genuinely useful thing to measure — but it is not the number Google uses to rank you, and it is not the number your users experienced. Those come from field data, and the two disagree often enough that reading a lab score as your ranking status will send you fixing the wrong thing.
Two numbers, measured two completely different ways
Lab data (synthetic). Lighthouse loads the page once, in a controlled environment: a specific throttled CPU and network, a specific viewport, no real user, no real cache. Because everything is fixed, the result is reproducible and diagnosable — the same page under the same conditions gives you the same waterfall, the same opportunities, the same score (within run-to-run variance). This is what a PageSpeed score, a DevTools Lighthouse run, and a CI performance check all are.
Field data (real users). Google's Chrome User Experience Report (CrUX) collects Core Web Vitals from actual Chrome users who visited your page — on their real phones and laptops, their real networks, their real cache states, from wherever they are. It's aggregated over a trailing 28-day window, and the headline figure is the 75th percentile: the experience at least three-quarters of your page loads were at least as good as. This is what the "Core Web Vitals" report in Search Console shows, and it is the input to Google's page-experience ranking signal.
One is a controlled single measurement you can run whenever you want. The other is a 28-day distribution of experiences you can only observe, never trigger.
Which one ranks you
The ranking signal is the field number — the CrUX 75th percentile, not your Lighthouse score. Google has been explicit about this: the page-experience signal uses field Core Web Vitals, and the Lighthouse performance score is a diagnostic, not a ranking factor. So a page can score 100 in Lighthouse and still fail Core Web Vitals in Search Console, and a page with a mediocre lab score can pass — because real users, on median hardware with a warm cache, had a better time than one cold throttled synthetic run implies, or a worse one.
It matters which metrics, too. The three Core Web Vitals are:
- LCP — Largest Contentful Paint. Measured in both lab and field.
- INP — Interaction to Next Paint. This is a field-only metric; it needs real user interactions to measure. Lighthouse can't produce an INP because there's no user clicking, so a lab run reports Total Blocking Time (TBT) as its closest proxy. TBT and INP correlate, but they are not the same number, and a great TBT does not guarantee a passing INP. (INP replaced First Input Delay as a Core Web Vital in March 2024.)
- CLS — Cumulative Layout Shift. Measured in both, but the field version accumulates over the whole visit including scroll-triggered shifts a single lab load never reaches.
So even before the environment differences, one of the three ranking metrics can't be produced in the lab at all. That alone means a green lab report is not a statement about your INP.
Why they disagree
The lab and field numbers drift apart for structural reasons, not because one is broken:
- One run vs. a distribution. Lab is a single cold load. Field is millions of loads across the cache states, devices, and networks of your real audience — and it reports the p75, so a slow tail of users on bad connections drags it in a way one clean synthetic run never shows.
- Cold cache vs. warm. Lighthouse loads uncached. Returning real users hit warm caches and often see much faster LCP — field can be better than lab.
- Throttling assumptions. Lab picks one throttled profile. If your actual audience is mostly on fast devices, field beats lab; if they're mostly on slow mobile in a region you didn't model, field is worse.
- Interaction reality. TBT is measured with no one interacting; INP is measured because someone did. A page that looks calm in the lab can jank badly under a real user mashing a filter.
None of this makes the lab number useless. It makes it a different question.
The lab number is your early-warning system — so watch it
Here's the trap the field/lab split sets: because ranking uses field data, teams learn to watch Search Console's Core Web Vitals report — which is a 28-day trailing p75. That means the day you ship a regression, the field number barely moves. It takes weeks for enough real-user samples to accumulate before the p75 crosses a threshold and Search Console turns the URL group red. By then the regression has been live, and losing you rankings, for most of a month.
The lab number doesn't have that lag. A synthetic run reflects the regression the moment you deploy it. That's the whole reason the lab test exists:
- You can run it on demand, on a PR, before you ship. You cannot A/B a field metric on a pull request; you can run Lighthouse on a preview build.
- It's reproducible, so a change is attributable. If the lab LCP jumps 800ms between two deploys, you know which deploy — the field p75 can't tell you that for weeks.
- A lab regression precedes the field regression. The heavy hero image, the added third-party script, the render-blocking font that shipped today degrades the lab number today and the field p75 a month from now. Catch it in the lab and you fix it before it ever reaches the number that ranks you.
So the honest way to use the two: field is the scoreboard, lab is the smoke detector. You're graded on field, but you defend the grade by watching the lab number continuously, because it moves first.
The free PageSpeed & Core Web Vitals checker runs the lab test — the same Lighthouse engine, via the PageSpeed Insights API — and gives you the 0–100 score plus LCP, CLS, and TBT on mobile or desktop, with Google's good / needs-improvement / poor bands. It's the on-demand smoke detector: run it on a page, run it after a deploy, run it on a competitor. It's a lab number by design, so read it as an early warning, not as your Search Console status.
What to do with each
- For a ranking question ("is this page passing Core Web Vitals for search?"), look at field data: Search Console's Core Web Vitals report, or the CrUX field section of PageSpeed Insights. That's the p75 real-user experience Google actually uses.
- For a why and a *fix* ("what's slow and what changed"), look at lab data: the Lighthouse run, its waterfall and opportunities. That's the reproducible, attributable, run-it-now number.
- To not get surprised, watch the lab number continuously, not once — because the field p75 you're graded on lags a deploy by weeks, and the lab number that predicts it doesn't.
The one-line version: your PageSpeed score is a controlled lab run you can trigger any time; Google ranks you on a 28-day p75 of real users you can only observe — so treat the lab number as the early warning for a field regression that won't show up for weeks.
And a lab regression is exactly the kind of thing that ships silently: a new image, a heavier analytics tag, a font that started render-blocking after a dependency bump. Merlonix re-runs the lab measurement on your pages on a schedule, tracks the score and Core Web Vitals over time, and alerts you the moment a metric crosses into "poor" — the same way it watches SSL and DNS and broken links: continuously, from outside your stack, so a performance regression is something you hear from monitoring instead of from your rankings a month later. Run the free PageSpeed check to see where a page stands right now, and browse the rest of the free tools while you're there.
Originally published on the Merlonix blog.
Top comments (0)