The report says 98. The Search Console report says the same pages are failing Core Web Vitals. Someone concludes that one of the tools is broken.
Neither is. They are answering different questions, and knowing which question you asked is most of what makes performance work productive rather than circular.
What each measurement is
Lab data - Lighthouse, WebPageTest, the browser performance panel - loads your page once, on a simulated device, on a simulated network, with an empty cache and no human behaviour. It is a diagnostic instrument. Its value is that it isolates variables and shows you a waterfall, which is how you find out why something is slow.
Field data - the Chrome User Experience Report, and any real-user monitoring you run - records what happened to actual people on actual devices. It is not reproducible, it has no waterfall, and it is the measurement your business and search engines both actually use.
A perfect lab score tells you the page can be fast. Field data tells you whether it is.
The five reasons they disagree
- You tested the wrong page. Lab tests default to the homepage. Real traffic lands on a product page, a category page or an article, which have different templates, different scripts and usually more of both.
- You tested logged out and with an empty basket. Personalisation, session logic and cart contents add work that no anonymous test performs.
- Consent had not been given. Run before a cookie banner is accepted, the page loads none of the tags that real visitors load a second later. This single difference explains a large share of the gap on marketing sites.
- The device is not the device. Lab throttling approximates a mid-tier phone. A meaningful share of real traffic is on something slower, on a worse network, in a browser with less memory available.
- Interaction never happened. INP measures responses to real taps across a whole visit. A lab run that loads a page and stops cannot produce an INP figure at all - what it reports is a proxy.
How to run the comparison properly
Before changing anything, make the lab test resemble the visit.
Test the template that carries the traffic, not the homepage. Accept the consent banner first. Test with a populated basket or a logged-in session if that is what your visitors have. Test on the device class your analytics says is common, not the one you own.
Most of the time the score drops sharply at that point, and the "contradiction" turns out to be a measurement that was never about your visitors.
What to act on
Use field data to decide whether you have a problem and which pages have it. Use lab data to find out why. Reversing that order is how teams spend a quarter optimising a page nobody visits.
And treat the score itself as a summary, not a target. It is a weighted average of several metrics; a page can gain points by improving something no visitor perceives while the metric that is actually failing does not move. The individual metrics - and specifically the one that is failing in the field - are the thing to work on.
When the field data is the thing that is wrong
Occasionally the field data is genuinely misleading, and it is worth knowing when.
Field data is reported at the 75th percentile over a rolling window, so it lags a fix by weeks - a change deployed on Monday will not show cleanly for a month. It also aggregates by URL group, which can mix a fast template with a slow one under one heading. And it needs traffic: a low-volume page may have no field data at all, which is not the same as passing.
None of that makes lab data the better measure. It makes patience part of the method: fix the dominant constraint, wait for the window, then look again rather than re-testing in the lab and declaring victory the same afternoon.