Core web vitals scores versus what users actually feel

The green checkmark doesn’t mean what you think it means

I’ve had pages sit at “good” across all three Core Web Vitals in Search Console and still get a message from someone saying the site feels sluggish. I’ve also had pages that fail a lab test in PageSpeed Insights and never hear a complaint from a real visitor. That gap is the whole subject of this post, and it’s worth understanding before you spend a week shaving 200 milliseconds off a metric nobody experiences.

Core Web Vitals are three specific measurements: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). Each one measures something narrow and well-defined. None of them measures “does this feel fast,” even though that’s how people talk about them.

What the three metrics actually track

LCP measures how long it takes for the largest visible element, usually a hero image, a big block of text, or a video poster, to render on screen. It’s a proxy for “when does the page look loaded,” not “when is the page usable.”

INP replaced First Input Delay as the official responsiveness metric in March 2024. It samples every interaction a user makes across the full lifetime of the page visit, a click, a tap, a keypress, and measures the time from that interaction to the next visual update. It reports something close to the worst interaction a user had, not the average. A page can feel snappy for nine clicks and then hang for one, and that one click is what shows up in your INP number.

CLS measures unexpected layout movement, the kind that happens when an ad slot loads late and pushes your text down while you’re mid-read. It only counts shifts that happen without a recent user interaction, which is a deliberate design choice, not an oversight. A layout change triggered by something you clicked on doesn’t count against you.

Each of these is a real, useful signal. The problem is what they leave out.

Lab data and field data are answering different questions

PageSpeed Insights gives you two very different numbers on the same report, and a lot of people never notice the distinction. The lab data is a synthetic test: a simulated device, a simulated throttled connection, run once, in a lab. The field data, when it’s available, comes from the Chrome User Experience Report (CrUX), which aggregates real measurements from real Chrome users who visited your page with their actual devices and actual connections, over a rolling 28-day window.

These two numbers can disagree, and both can be “right.” A lab test run on a simulated mid-tier mobile device on a throttled connection will often look worse than what your actual visitors experience, especially if most of your traffic comes from desktop users on decent broadband. I’ve watched a lab score sit in the “needs improvement” range on a page where the field data, pulled from actual visitors, was solidly green. Chasing the lab number down to zero would have meant optimizing for a user who barely shows up in the analytics.

The reverse happens too. A page can lab-test beautifully because the tester’s simulated conditions don’t reproduce what your slowest real segment deals with, a specific carrier, an older Android device, a shared hotel wifi connection. Field data catches that. Lab data often doesn’t.

If you’re only looking at the lab score in PageSpeed Insights and never opening the Page Experience report in Search Console, you’re optimizing against a simulation instead of the population that actually visits your site.

Where a passing score and a slow feel split apart

Here’s the part that matters most if you run sites for a living instead of studying the spec. There’s a long list of things that make a page feel slow or janky that none of the three Core Web Vitals metrics capture.

A page can pass LCP because the hero image renders fast, and still feel unfinished because the fonts swap in late and everything visibly flashes. Font swap isn’t scored directly, it just happens to sometimes contribute to layout shift if the swap changes text dimensions, and sometimes it doesn’t shift anything at all, it just looks bad.

A page can pass INP because the sampled interactions were all fast, while a specific, important interaction, say, an “add to cart” click that triggers a slow API call, happens rarely enough in the sample that it doesn’t drag the p75 number down, even though it’s the exact interaction that matters most to your conversion rate.

A page can pass CLS while still having jank that users feel: janky scrolling caused by heavy scroll-linked animations, layout shifts that happen inside the exemption window right after a click, or content that loads in below the fold and shifts things only for users who scroll that far, which CLS still counts but which might feel different depending on when the user notices it.

None of this means the metrics are wrong. It means they’re specific measurements of specific moments, not a general-purpose “does this feel good” score. Treating a green Core Web Vitals badge as proof the site feels fast is the same mistake as treating a clean XML sitemap as proof the site is well structured. It’s one input, not the whole picture.

The 75th percentile hides your worst visitors on purpose

Google scores Core Web Vitals at the 75th percentile of page loads or user experiences, not the average and not the worst case. That threshold is deliberate: it means a quarter of your visits can be having a genuinely bad experience and your site can still show as “good” across the board.

If your traffic includes a meaningful chunk of users on older devices, weak connections, or markets where mobile data is inconsistent, that bottom quartile can be a real slice of real people who are having a rough time, invisible in the top-line score. I don’t chase p75 to zero, but I do check the distribution when I have a segment I care about, rather than trusting the single pass or fail badge.

What I actually check now

I stopped treating the PageSpeed Insights lab score as the target years ago. What I check instead, in order: the Page Experience report in Search Console for real field data segmented by page group, whether INP problems cluster around one specific interaction rather than the page as a whole, and whether CLS issues trace back to a specific ad unit or embed rather than my own layout code, since those are usually the actual culprits.

I also stopped assuming a Core Web Vitals fix moves rankings on any predictable timeline. Google has described page experience signals as one factor among many, and I’ve never seen a clean, isolated ranking jump from a Core Web Vitals fix on my own sites where I could rule out everything else that changed in the same window. I treat it as a real signal worth fixing because it’s genuinely connected to whether people stick around and convert, not because I can point to a guaranteed ranking outcome from fixing it.

A tactic I’ve stopped bothering with

Chasing a 100 score in PageSpeed Insights lab data, on a page that already has good field data in Search Console, is a tactic I’ve dropped entirely. It’s hours spent optimizing for a synthetic device profile that may not resemble your actual traffic, in pursuit of a number Google doesn’t even use as the scoring input. If the field data is green and users aren’t complaining, that time is better spent on content, internal linking, or literally anything with a clearer connection to outcomes you can measure.

Core Web Vitals are worth fixing because they’re a decent proxy for real frustration, a slow-loading hero image, a laggy button, a page that jumps around while you’re reading it. But the number in the report and the feeling in your gut when you use the page are two separate things, measured two separate ways, and conflating them is how you end up optimizing the wrong thing for a week.

If you want help figuring out which of your pages actually have a field data problem versus a lab data illusion, that’s the kind of technical SEO work we do at The SEO Desk.