Lab Scores Lie: PageSpeed Says 98 and Users Still Wait
Kalyani Coffee sells single-estate beans out of Pune. Their developer sent the founder a screenshot: 98 in PageSpeed Insights, three green circles, a small victory lap in the email. Two weeks later Search Console flagged the product templates as needing improvement. The founder assumed someone was lying. Nobody was. A lab score and a field report can disagree completely and both still be accurate, because they are answers to two different questions. This is the CrUX field data vs lab data gap, and once you see it you cannot unsee it.
The metrics themselves are not in dispute. Good means LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1, measured at the 75th percentile of field data over a rolling 28-day window. Read that sentence twice. Every trap is inside it.
- A lab score is one simulated visit on one device. Field data is what real visitors experienced.
- Assessment uses the 75th percentile over 28 days, so your slowest quarter of visitors decides the verdict.
- Lab tools cannot measure INP at all, because nothing clicks anything.
- The CrUX field data vs lab data gap is widest on sites with varied devices, networks or logged-in states.
- Use a lab score to debug. Use field data to decide whether you have a problem.
- Two Numbers Measuring Two Different Things
- Why the 75th Percentile Is So Unforgiving
- Six Reasons Your CrUX Field Data vs Lab Data Gap Is Wide
- Which Number to Use, and When
- The Percentile Math, Done Once
- What Kalyani Coffee Found
- The Objection Every Developer Raises
- How to Tell Whether the Fix Worked
- A Plain Guide for Non-Technical Owners
Two Numbers Measuring Two Different Things
A lab score comes from a synthetic test. A tool loads your page once, on a defined device profile, over a defined connection, from a defined location, with no cookies and nobody clicking. It is reproducible, which is exactly why it is useful for debugging and useless as a verdict.
Field data comes from real Chrome users who opted in to reporting, aggregated in the Chrome User Experience Report. Their phones are three years old. Their connections drop in a lift. They arrive logged in with a full cart and a stored session. They tap things.
- One simulated load, one device profile
- Reproducible and instant
- Shows you why something is slow
- Cannot measure INP, because nothing interacts
- No cookies, no session, no logged-in state
- Great for before-and-after during a fix
- Real visitors, real devices, real networks
- 75th percentile over a rolling 28 days
- Shows you whether you have a problem
- Measures all three Core Web Vitals properly
- Needs enough traffic to report at URL level
- Moves slowly, which punishes impatience
Why the 75th Percentile Is So Unforgiving
Averages hide misery. Percentiles do not. Assessment at the 75th percentile means three quarters of your visits must meet the threshold before you pass. Your test on office wifi is somewhere near the 10th percentile of your own audience and tells you almost nothing about the rest.
Six Reasons Your CrUX Field Data vs Lab Data Gap Is Wide
| Cause | Why the lab test misses it |
|---|---|
| Older mid-range Android devices in your audience | The test profile is usually faster than your median visitor's phone |
| Third-party scripts that only fire for real sessions | Consent-gated or logged-in tags may not load in a clean synthetic run |
| Interactions, forms, filters, menus | Nothing clicks in a lab run, so INP is simply absent |
| Geographic spread of your traffic | One test location cannot represent tier-2 city latency |
| Cache state on repeat visits | Lab tests are cold; your real mix is cold and warm together |
| Origin-level rollup on low-traffic URLs | Your page may be judged on the whole origin's data, not its own |
That last row surprises people. If a URL does not have enough samples, reporting falls back to a group or to origin-level data. A fast product page can be marked poor because the origin it belongs to is dragged down by templates you never looked at.
Which Number to Use, and When
The Percentile Math, Done Once
Do this arithmetic yourself a single time and the argument ends. Take twenty visits to one product page in a week. Fourteen of them come from newer phones on good connections and record an LCP of about 1.5 seconds. The remaining six come from three-year-old mid-range Android handsets on congested mobile data and record about 3.2 seconds.
| Way of reading the same twenty visits | Value | Verdict |
|---|---|---|
| Your own test on office wifi | 1.4s | Passes, and proves nothing |
| Average across all visits | 2.0s | Passes, and hides the six |
| 75th percentile, the one that counts | 3.2s | Fails |
The average is comfortably under 2.5 seconds. The assessed value is not, because the 75th percentile lands inside the slow cohort by construction. Making the fast fourteen half a second faster moves the average and changes the verdict not at all. The only work that counts is work that moves the slowest quarter, which is precisely the quarter your lab score never sampled.
What Kalyani Coffee Found
Illustrative, but the pattern repeats on most small ecommerce sites we open.
Their homepage genuinely was fast. The 98 was honest. Their product template was not, and it was where nearly all the traffic went. Two things were wrong. A grind-selection control rebuilt a price block on every change, which made INP miserable on older phones. And a review carousel loaded a font late, so the layout shifted after the hero settled, which the lab run never caught because it ran on a warm CDN edge close to the test location.
Both showed up in ninety seconds of throttled tracing once field data pointed at the right template. Nobody needed a new host. Nobody needed a rebuild. They needed to stop testing the one page that was already fine.
The Objection Every Developer Raises
"If the field numbers lag a month and the lab score is instant, why should I not just optimise against the tool that answers immediately?"
Because the fast answer is answering a question nobody asked. A lab score tells you how one clean load behaves on one device profile. Nothing in it is affected by your consent banner firing on a real session, by a customer arriving with a full cart, or by anyone tapping a filter. Optimise against it long enough and you will produce a page that is genuinely excellent under conditions none of your customers are in.
The honest version of the objection is about the wait, not the tool, and the answer to that is your own monitoring rather than a different score. Real-user data you collect yourself gives you tomorrow-morning resolution on the same metrics the field report will confirm four weeks later. Use the lab score for the diagnosis it is good at and stop asking it for a verdict it was never able to give.
How to Tell Whether the Fix Worked
Decide the answer before you ship, in writing, so that nobody relitigates it in week two.
- Record the failing template's current 75th-percentile value and the date you shipped
- Watch your own real-user data daily for the first week, split by device class
- Expect the mid-range Android segment to move first, since that is where the slack was
- Leave the field report alone for four full weeks, then read it once
- Re-run the lab score only to confirm you did not undo the fix in a later release
A fix has worked when the slow segment in your own monitoring has moved and the field value follows it a month later. If your monitoring moved and the field value did not, your traffic mix changed or the URL is being judged at origin level. If neither moved, you fixed something the slow quarter was never waiting on.
A Plain Guide for Non-Technical Owners
- Ask for the field section of the report, not the score circle
- Ask which template failed, not whether the site passed
- Ask what the 75th-percentile value was, in seconds or milliseconds
- Ask when the fix shipped, then check again after four full weeks
- Be suspicious of any report that only shows a green number and no dates
- A 98 lab score and a failing field report are both correct, because they measure different things.
- Thresholds are LCP under 2.5s, INP under 200ms, CLS under 0.1 at the 75th percentile over 28 days.
- Lab tools cannot measure INP, so a green lab score says nothing about responsiveness.
- Decide with field data, debug with the lab score, then wait out the window before judging the fix.
- Once your team understands the CrUX field data vs lab data split, performance arguments get much shorter.
DL Minds Performance Team
Digital marketing and web development expert at DL Minds. Passionate about helping businesses grow through innovative technology solutions and strategic digital marketing.
