You run PageSpeed Insights, the score comes back 96, everything is green, and you close the tab. A month later Google Search Console tells you the same page is failing Core Web Vitals. Both are talking about the same three metrics. Both are from Google. And they disagree.
This isn't a bug. They are measuring two different things, and only one of them is the one Google ranks on. If you have ever been confused about why your Lighthouse score and your real Core Web Vitals don't match, this is the reason, and it changes how you should measure performance.
Two kinds of measurement
There are two ways to measure Core Web Vitals, and almost every performance mistake comes from confusing them.
Lab data is a synthetic test. A tool like Lighthouse loads your page once, in a controlled environment: a simulated mid-range phone, a throttled network, an empty cache, no browser extensions, from one location, with nobody actually using the page. It's a laboratory in the literal sense, a clean room with one variable at a time. PageSpeed Insights runs this and gives you a score out of 100.
Field data is what happened to real people. Every visitor's browser can measure how the page actually performed for them and report it back: their real device, their real network, their real distance from your server, their real interactions. Google collects this at scale into the Chrome User Experience Report (CrUX), and this is the data behind the Core Web Vitals assessment in Search Console.
Here is the part that catches people out: Google ranks on the field data, not the lab score. The Lighthouse number is a diagnostic. The field data is the verdict. You can score 100 in the lab and still fail the assessment that affects your search ranking, because your real users are having a different experience than your clean-room test.
Why they diverge
Once you see lab and field as different measurements, the gaps between them stop being mysterious. Every one of these pushes real users away from your lab result:
- Real devices are all over the map. Lighthouse simulates one mid-range phone. Your actual traffic is a spread from flagship phones to five-year-old Androids that render JavaScript far slower. Your p75 user, the one Google cares about, may be nothing like the simulated device.
- Real networks are worse and more variable. A throttled lab connection is a single fixed condition. Real users are on hotel wifi, congested mobile, trains going through tunnels. The tail of that distribution is long, and Core Web Vitals is judged at the 75th percentile, not the average.
- Geography is real. Lab tests usually run from somewhere near Google's servers. If a chunk of your users are a continent away from your origin, their TTFB and LCP carry latency your lab run never sees.
- Cache states differ. Lab runs cold, every time. Real traffic is a mix of first visits and repeat visits with warm caches. Neither number alone is the truth; the field distribution is.
- Third parties misbehave in the wild. That analytics script or embed that loaded instantly in your one lab run might be slow, or fail, for real users at 9am on a Monday. Field data catches the bad days. A single lab run cannot.
None of this makes lab data wrong. It makes it narrow. It is one sample from a controlled setup, and your users are a distribution from an uncontrolled one.
INP is the clearest case
If you want the sharpest example of why field data matters, look at INP (Interaction to Next Paint), the metric that replaced FID.
INP measures how quickly your page responds when a user actually interacts with it: taps a button, opens a menu, expands an accordion. To measure it, someone has to interact. A lab test loads the page and sits there. It can flag potential responsiveness problems by looking at main-thread work, but it cannot measure your real INP, because it never clicks anything.
So for INP specifically, lab data isn't just narrow, it's structurally incapable of giving you the real number. The only way to know your INP is to measure real interactions from real users. This is field data by definition.
Why the 75th percentile, and not an average
Field data comes as a distribution, and Core Web Vitals is assessed at the 75th percentile of it. That choice matters.
An average hides your worst experiences. If most of your users are fast but a quarter of them are having a genuinely bad time, the average still looks fine, and those users still bounce. The p75 says: three out of four visits must be good. It deliberately holds you to the experience of your slower quarter, not your median.
This is also why a single lab number is a poor proxy. One run gives you one point. The assessment that ranks you is about the shape of the whole distribution, specifically its tail. You cannot see a tail with one sample.
So what is lab data good for
Everything above sounds like an argument to throw away Lighthouse. It isn't. Lab and field do different jobs, and you need both.
Lab data is for debugging. It is reproducible, it isolates variables, and it hands you a waterfall: which resource blocked rendering, which element is your LCP, what script ate the main thread. When something is slow, lab tools tell you what to fix. That is genuinely valuable and field data can't do it, because field data tells you that users are slow without handing you a controlled trace to dig through.
Field data is for measuring. It tells you whether your users are actually having a good experience, whether you are passing the assessment Google ranks on, and whether the fix you shipped last week actually helped the people it was meant to help.
The mistake is using one for the other's job. Debugging against field data is frustrating because it isn't reproducible. Measuring success against a lab score is misleading because it isn't real. Use the lab to find the problem, use the field to confirm it's solved.
The practical setup
Put plainly, here is the workflow that avoids the trap:
- Measure your real users continuously and watch the p75 of LCP, INP and CLS. This is your source of truth, and it's what tells you whether you have a problem at all.
- When the field data shows a regression, reach for lab tools to reproduce and diagnose it. Get the waterfall, find the offending element or script, fix it.
- Confirm the fix in the field, not the lab. A green Lighthouse score after your change means the lab is happy. Watching your real p75 come down means your users are.
The piece most teams are missing is the first one. Almost everyone has run PageSpeed. Far fewer are collecting real-user metrics continuously, which means they are measuring performance with the one tool that doesn't reflect their users, and finding out they're failing from Search Console weeks later.
Collecting field data is not hard. The browser exposes every Core Web Vital through the web-vitals library or the underlying Performance APIs; you attach listeners, batch the metrics into one small beacon, send it on page unload, and aggregate at p75 over time. If you want the exact code for a Next.js app, I wrote that up separately in How to Track Core Web Vitals in Next.js.
Or you can skip the build. JAMP collects real-user Core Web Vitals from every visitor, reports LCP, INP and CLS at p75, tracks them over time and per release, and pairs the field data with on-demand lab audits in the same place, so you have the "what to fix" and the "did it actually get better" side by side. It's cookieless, the script is under a kilobyte, and real-user vitals are on the free tier. You can see it running on real data without signing up.
Whichever route you take, the rule is the same: debug in the lab, but measure in the field. The green score is a hint. Your real users are the answer.