This is one of the most confusing moments in technical SEO: a site scores 100 in PageSpeed Insights, everything looks green, and the developer moves on satisfied only for Search Console to keep reporting failing Core Web Vitals for the same pages. Neither report is wrong. They’re measuring two genuinely different things, and understanding the difference is the difference between fixing a real problem and chasing a green checkmark that doesn’t matter.
Two completely different kinds of data
Lab data, also called synthetic testing, is what tools like Lighthouse, PageSpeed Insights, GTmetrix, and WebPageTest actually produce. These tools load your page once, in a controlled, simulated environment — a fixed device profile, a fixed network throttle, a fixed location and report how it performed under those specific conditions. It’s useful precisely because it’s controlled and reproducible: run the same test twice and you’ll get a similar answer, which makes it genuinely good for debugging a specific change and confirming whether a fix actually worked.
Field data is the opposite kind of measurement entirely. Also called Real User Monitoring, it’s collected from actual visitors using your site in the real world — real devices, ranging from high-end phones to years-old budget Android handsets, real networks, ranging from fiber to spotty mobile data, and real behavior, including whatever else a visitor’s device happens to be doing at the time. Google’s version of this is the Chrome User Experience Report, commonly called CrUX, which aggregates anonymized performance data from real Chrome users who’ve opted into sharing it, specifically at the 75th percentile over a rolling 28-day window.
Which one Google actually uses for ranking
This is the part that resolves the confusion: Google’s page experience signals are based on field data, not lab data. The 100 score in Lighthouse is a helpful diagnostic, but it isn’t what Search Console’s Core Web Vitals report is evaluating, and it isn’t what factors into ranking. Field data is the one that reflects your actual audience’s actual experience, which is also why it’s the one that matters for the business a lab score describes a single simulated visit under ideal conditions, while field data describes what real users on real, often worse, hardware and networks are genuinely getting.
Why the two numbers can disagree so sharply
A handful of structural reasons explain most of the gap. Lab tests typically simulate one device profile and one network speed, usually a mid-range device on a throttled but consistent connection, while your real traffic includes a much wider mix older phones with less processing power, users on genuinely poor mobile connections, and everything in between. A page that renders quickly on the specific device profile Lighthouse simulates can still render slowly for a meaningful share of your actual visitors on weaker hardware.
Lab tests are also typically run from a specific, often US-based, testing location with a clean network path to the server, while field data reflects wherever your real users actually are and a visitor several thousand kilometers from your server, or on a congested network, will see a meaningfully worse experience than a lab test run from an optimized location, regardless of how well the page itself is built. This is exactly the same geographic effect that drives real-world TTFB variation, just showing up across the full Core Web Vitals picture rather than one metric.
Interaction to Next Paint is particularly prone to this gap, because it depends entirely on real user interaction clicking, tapping, typing and a synthetic test can only simulate a generic interaction pattern, not the specific, sometimes rapid-fire way real users actually behave on a real page. A page that handles one simulated click smoothly can still feel sluggish to a real user tapping through a form quickly on a mid-range phone.
And field data is aggregated at the 75th percentile across 28 days of real traffic, which means it’s inherently smoothing over your worst-performing sessions, your slowest devices, and your most congested network conditions all of which a single lab test, run once under favorable conditions, simply never encounters.
The scale of the gap is bigger than most teams assume
This isn’t a rare edge case. Google’s own Chrome UX Report data for the industry-wide origin dataset showed only 55.9% of measured origins passing all Core Web Vitals thresholds in the field, even as the same sites often score comfortably in Lighthouse. Nearly half the measured web is failing the real-world standard while frequently looking fine in a synthetic test, which tells you the lab-passes-field-fails pattern isn’t unusual it’s closer to the norm.
What to actually do when the two disagree
Treat field data as the one that matters for business impact and ranking, and treat lab data as the diagnostic tool for finding and confirming fixes. When Search Console flags a page as failing in the field despite a clean lab score, the practical next step is checking which specific metric is failing — LCP, INP, or CLS — since each has different causes, and then using lab tools to reproduce that specific problem under conditions closer to what your real audience experiences, rather than the tool’s default profile. If a meaningful share of your traffic comes from older devices or slower networks, testing with a more aggressive throttle setting, or a lower-end device profile, in your lab tools will surface problems the default test configuration simply won’t catch.
The underlying lesson is that a perfect Lighthouse score was never actually the goal it’s a convenient proxy that happens to correlate with good real-world performance often enough to be useful, but it isn’t the same thing as good real-world performance, and treating it as the finish line is how teams end up confused when the metric that actually matters keeps failing anyway.
