Why Your Website's Core Web Vitals Score Doesn't Match What Users Actually Feel

A client came to us with a 96 on PageSpeed Insights and a bounce rate that kept climbing. Their developer had done everything the audit asked: compressed images, deferred non-critical CSS, inlined the above-the-fold styles. The score was excellent. The site still felt slow, and the data said so too.

This isn't a rare situation. It's the default outcome of treating a Lighthouse score as the goal instead of a proxy for one.

What Core Web Vitals actually measure

Largest Contentful Paint, Cumulative Layout Shift, and Interaction to Next Paint are good metrics. They correlate with real user experience better than almost anything Google has shipped before them. But they're measured on a synthetic run, usually a cold load with no user behavior, on a device profile that may not resemble your actual traffic.

A store with a fast LCP because the hero image is small and low-quality will score well and still feel cheap to a visitor deciding whether to trust you with a credit card. A dashboard that hits every green metric on load can still feel sluggish once someone starts clicking through filters, because none of the three metrics measure sustained interaction quality after the first paint.

The gap is usually in what happens after "loaded"

Most real complaints about a "slow" site aren't about the first paint at all. They're about:

• A search filter that takes 400ms to update the list, every single time, with no visual feedback in between
• A checkout button that responds instantly but doesn't reflect the loading state, so users click it twice
• Images that load fine individually but shift the layout as they resolve, even with a CLS score under 0.1
• A single-page app that's fast on navigation but re-fetches data users already saw thirty seconds ago

None of this shows up clearly in a lab score, because a lab score runs once, cold, and stops measuring once the page is "interactive." Your users keep interacting for minutes.

What we actually check instead

Lab scores are a floor, not a target. Once a site clears reasonable Core Web Vitals thresholds, we shift to field data and direct observation: real user monitoring segmented by device and connection type, session recordings on the specific flows that matter (checkout, signup, search), and time-to-first-meaningful-interaction on the actual data volumes a production account has, not a seeded demo with twelve sample rows.

That last point catches more real slowness than anything else. A table that renders instantly with 20 rows and chokes at 2,000 will pass every lab test, because nobody tests load performance with production-scale data before launch. We do, specifically because it's the gap between "the audit passed" and "the client's ops team hates using this."

The fix isn't always more optimization

Sometimes the honest answer is that the site is fast enough and the perceived slowness is a UX problem wearing a performance costume: no loading state, no optimistic UI update, no skeleton screen during a fetch. Users don't experience milliseconds. They experience whether something felt responsive to what they just did. A 300ms fetch with a visible spinner reads as faster than a 150ms fetch with a dead, unresponsive-looking screen in between.

If you're chasing a perfect Lighthouse score and your bounce rate hasn't moved, the metric probably isn't the problem anymore. Look at what happens after the page paints, on your real data, on the devices your actual visitors use. That's usually where the real gap is hiding.