It's a common frustration: the PageSpeed report says 95, Core Web Vitals are all green, and yet real visitors still describe the site as slow. This isn't a contradiction, it's a gap between two different things that get conflated as "speed."
Lab data versus real-world data
Tools like PageSpeed Insights and Lighthouse run what's called lab testing: a simulated visit from a clean browser, on a controlled connection, with no interference from ad blockers, extensions, or a visitor's actual device. Real-world data, sometimes called field data, comes from actual visitors on actual devices over actual connections, which vary wildly.
A site can score well in the lab and still feel slow in the field because the lab test doesn't account for a five-year-old Android phone on a patchy 4G connection, which is a completely normal real-world scenario for a meaningful share of any site's traffic.
The metrics that matter more than the overall score
Google's own Core Web Vitals documentation breaks real-world experience down into three metrics that matter more than a single overall score:
- Largest Contentful Paint (LCP): how long until the biggest visible element loads. This is the metric most closely tied to a visitor's perception of "is this page ready yet"
- Interaction to Next Paint (INP): how responsive the page feels when someone actually clicks or taps something, not just how fast it loaded
- Cumulative Layout Shift (CLS): whether content jumps around as the page loads, which feels chaotic even on a technically fast connection
A page can have a fast initial load and still feel broken if buttons take a second to respond after tapping, or if an image loads late and pushes the text you were about to read down the screen. Neither of those failures necessarily shows up clearly in a single overall score.
Why this gets missed
Most speed audits stop at the lab score because it's the easiest thing to measure and report on. Real-world data requires either enough traffic to populate the Chrome User Experience Report, or dedicated monitoring, and interpreting it takes more judgement than reading a single number. It's genuinely easier to optimise for a good lab score than to fix what real visitors experience, which is exactly why the gap persists on so many sites.
What actually closes the gap
Testing on throttled connections and older devices, not just a fast office wifi connection on a new laptop. Checking Core Web Vitals field data in Google Search Console, which reflects real visitors rather than a simulation. Prioritising interaction responsiveness (INP) as much as initial load speed, since a fast-loading page that feels sluggish to interact with still drives visitors away. And treating layout stability as a real UX issue, not a minor technical detail, since a shifting page is one of the fastest ways to make a site feel untrustworthy even if it's objectively quick.
A quick way to check this on your own site
Open Chrome DevTools, switch to the Network tab, and set throttling to "Slow 4G" or similar. Reload the page you're worried about and actually watch it load, not just the final timer. Then check Search Console's Core Web Vitals report under the Experience section, which shows real visitor data grouped by URL. If the field data is noticeably worse than the lab score, that gap is exactly where the fix needs to focus, and it's usually more specific and more fixable than a vague "the site feels slow" complaint suggests. It's exactly the kind of check that belongs in any web design project from the start, rather than treated as an afterthought once the site is already live.