Why Your PageSpeed Insights Score and Core Web Vitals Disagree (Lab vs Field Data)

TL;DR

• The 0–100 score is lab data, a one-off simulated load on an emulated mid-range Android phone with a throttled connection, run from a Google data centre. It is not a ranking factor.
• The Core Web Vitals assessment (pass/fail) is field data, real Chrome users on your actual site over the last 28 days, measured at the 75th percentile. This is what Google uses in ranking.
• They disagree because they measure different devices, networks, and visits, and in INP's case, different things entirely.
• If they conflict: trust field data for priorities, use lab data for diagnosis. A red lab score with green field data is not an emergency. A green lab score with red field data is.

One Report, Two Different Instruments

PageSpeed Insights stitches together two data sources that share almost nothing:

Field data comes from the Chrome User Experience Report (CrUX): anonymised performance data from opted-in Chrome users as they browse your site. Google evaluates it at the 75th percentile, your page passes a metric only if at least 75% of real visits hit the "good" threshold (LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1).

Lab data comes from Lighthouse: a synthetic test that loads your page once, under fixed throttled conditions, and grades what it sees. It's a controlled experiment, brilliant for debugging, useless as a verdict on real user experience.

Six Reasons the Two Numbers Disagree

1. The score grades a device your visitors may not own

The mobile Lighthouse test simulates a Moto G Power, a 2020 budget phone, on slow 4G with a 4× CPU slowdown. That's deliberately close to a worst-case visitor. If your audience is UK desktop users on fibre, or iPhone users on 5G, your field data will beat your lab score by a mile. The reverse also happens: if you sell to markets dominated by low-end Android on patchy networks, field data can be worse than the lab run.

2. Lab tests are always a cold first visit

Lighthouse loads the page with an empty cache, once. Your field data includes every visit, and for most established sites a large share are repeat visitors with your CSS, fonts, and hero images already cached. A site with strong caching and loyal traffic will routinely fail lab LCP while passing it comfortably in the field.

3. INP does not exist in the lab

This is the big one in 2026, because INP is the most-failed Core Web Vital. INP measures how quickly the page responds when a real person clicks, taps, or types, and a synthetic test has no real person. Lighthouse substitutes Total Blocking Time (TBT), which only measures main-thread blockage during initial load. A page can post 0 ms TBT and a 95 lab score, then fail INP in the field because a chat widget or consent script chokes the main thread every time someone interacts. If your score and your INP assessment disagree, they aren't even measuring the same event. (More on that: fixing INP problems caused by third-party scripts.)

4. CLS is measured over different lifespans

In the lab, CLS only counts layout shifts during page load, a few seconds. In the field, CLS accumulates across the entire page session: the ad that injects itself mid-article, the cookie banner that pushes content down, the carousel that reflows on interaction. Late-loading ads with no reserved space are the classic case of "lab CLS 0.00, field CLS 0.28", see how to fix CLS caused by ads.

5. Field data lags your fixes by up to 28 days

CrUX is a rolling 28-day window. Ship a fix today and the field data still contains four weeks of the old, slow experience; it dilutes out gradually. Teams routinely fix an issue, re-test a week later, see the assessment still failing, and wrongly conclude the fix didn't work. The lab score updates instantly; the assessment catches up on a delay. (Full timeline: how long Core Web Vitals take to update.)

6. Your page might be showing someone else's data

Low-traffic pages don't get their own CrUX entry. PageSpeed Insights silently falls back to origin-level data: the aggregate of your whole domain. The label switches from "This URL" to "Origin", and it's easy to miss. You could be staring at a fast page that inherits a failing grade from a slow template elsewhere on the site.

So Which One Should You Trust?

Both, for different jobs.

The mistake we see most on client sites: teams optimising the lab score as if it were the ranking factor, burning dev sprints to go from 78 to 92 on a metric Google never reads, while the field INP failure that actually suppresses rankings sits untouched.

The Workflow That Actually Works

1. Start in Search Console, not PageSpeed Insights. The Core Web Vitals report groups failing URLs by template, that tells you where the problem lives and how many pages share it.
2. Confirm with field data in PageSpeed Insights (or the CrUX API). Check whether you're looking at URL-level or origin-level data first.
3. Diagnose with lab tools. Now Lighthouse earns its keep: the audits, filmstrips, and traces show why the metric fails, render-blocking CSS, unsized ad slots, long JavaScript tasks.
4. Verify with real-user monitoring, not the 28-day window. A lightweight RUM script (or the web-vitals JS library feeding your analytics) shows within days whether the fix works, instead of waiting a month for CrUX.

New to the terminology? Keep the Core Web Vitals cheat sheet open alongside this.

About the Author

Shakur Abdirahman

Technical SEO Specialist

Shakur is a Technical SEO Specialist who fixes Core Web Vitals at the template level, so improvements hold across thousands of URLs rather than one page at a time.

More about the author →

LinkedIn