You ran your site through Google PageSpeed Insights, got a score in the 90s, and felt good about it. Then a customer mentioned the site felt sluggish, or you loaded it yourself on your phone over a spotty connection and watched it crawl. Both things can be true at once, and the reason comes down to what that score is actually measuring.
PageSpeed Insights gives you two different reports, not one
When you run a PageSpeed test, you get back two distinct kinds of data, and most people only look at the score without realizing they’re blended together.
Lab data is a simulated test. Google’s tool loads your page once, under fixed conditions (a specific device profile, a specific simulated network speed, from a specific location) and measures what happens. It’s consistent and repeatable, which makes it useful for testing changes, but it’s still just one simulated visit.
Field data is different. It’s built from real visits by real people who use Chrome and have opted into sharing performance data, aggregated over the past 28 days through what’s called the Chrome User Experience Report. This is what your actual customers experienced: on their actual phones, their actual WiFi or mobile data, in their actual location.
The gap between these two is exactly why a high lab score doesn’t always match what a visitor feels. The lab test is one clean run in ideal-ish conditions. The field data is thousands of runs across everything real life throws at a website: an older phone, a weak signal at a coffee shop, a first-time visitor with nothing cached yet.
Specific reasons the two disagree
A few concrete things explain the gap, and they matter because they point to what’s actually worth fixing.
Returning visitors load faster than the lab test assumes. Lab tests usually run cold, with nothing cached. A real returning customer has your logo, fonts, and scripts already stored in their browser from last time, so pages after the first one load noticeably faster than the lab number suggests.
Real interaction timing isn’t something a lab can predict. Interaction to Next Paint (INP), one of the three Core Web Vitals alongside Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS), measures how quickly your site responds when someone actually taps or clicks something. A lab test can guess at this, but it can’t replicate the moment a real visitor taps a menu right as three tracking scripts are still finishing their work in the background.
Layout shift adds up differently over a real visit. Cumulative Layout Shift (CLS) tracks things jumping around on the page, like a button moving just as someone was about to tap it because an image above it finally loaded. Lab tests mostly capture shifts during the initial load. Real visitors keep scrolling and interacting well past that point, so shifts caused by lazy-loaded images or late-arriving ads often show up in field data and never show up in a lab test.
Device and network variety is the biggest factor. Your lab test runs on one simulated device and one simulated connection. Your actual customers are on a mix of new phones and three-year-old phones, fast home WiFi and patchy mobile data. A site that feels instant on a lab-simulated mid-range device can feel genuinely slow on the older phone a real customer is actually holding.
What the actual thresholds are
For reference, here’s what Google currently considers good, needs improvement, and poor for each Core Web Vital:
Largest Contentful Paint (how fast the main content appears): good is under 2.5 seconds, needs improvement is 2.5 to 4 seconds, poor is anything above 4 seconds.
Interaction to Next Paint (how fast the page responds to a tap or click): good is under 200 milliseconds, needs improvement is 200 to 500 milliseconds, poor is anything above 500 milliseconds.
Cumulative Layout Shift (how much things move around unexpectedly): good is under 0.1, needs improvement is 0.1 to 0.25, poor is anything above 0.25.
These are the numbers that actually affect both how a visitor experiences your site and how Google evaluates it for ranking, which is a big part of why a lab score alone isn’t the full picture.
To see your own field data, run your URL through PageSpeed Insights and look for the section labeled “Discover what your real users are experiencing” near the top of the report, above the lab data. Google Search Console has the same numbers too, aggregated across your whole site rather than one page at a time, under the Core Web Vitals report in the left-hand menu.
Why this matters more than the number itself
A high lab score is a reasonable starting signal, but treating it as the finish line means real problems can hide in plain sight. A checkout button that shifts right as someone reaches for it, a menu that lags on a three-year-old Android phone, a page that only feels fast to returning visitors with a warm cache, none of that shows up in a single clean lab run. It shows up in field data, and more importantly, it shows up in whether a visitor finishes checking out or gives up and leaves.
This is also why a real conversion rate optimization audit doesn’t stop at a PageSpeed screenshot. It means looking at field data alongside the lab test, checking how the site actually behaves on a range of real devices, and treating layout shifts and interaction delays as seriously as the headline load time, because those are the moments where a visitor actually decides to stay or leave.
What to actually do with this
If you’ve been chasing a perfect lab score, it’s worth redirecting some of that attention toward your field data instead, since that’s the version of your site your customers are actually experiencing. If your PageSpeed report doesn’t show field data at all, that usually means your site doesn’t have enough real Chrome traffic yet for Google to report on it reliably, which is its own useful signal about traffic volume.
For what it’s worth, we hold this site to the same standard we’re describing here. The last lab audit of this site scored 95 on mobile and 97 on desktop for performance, with 100s across Accessibility, Best Practices, and SEO. It’s not a perfect number, and it isn’t meant to be. It’s a starting point we keep checking against real usage, the same way we’d recommend you do.
Either way, the goal isn’t a higher number. It’s a site that holds up for the actual person holding the actual phone, on the actual connection, trying to actually get something done on your site.