Core Web Vitals in Plain English

Jargon is a tax on understanding, and web performance jargon taxes at a punishing rate. LCP, INP, CLS. When site owners see these acronyms in a report, most of them do the sensible thing and stop reading. That’s a shame, because the ideas behind Core Web Vitals are not technical at all. They’re three ordinary annoyances that everyone who has used the web has felt, dressed up in initials so they can be measured. If you translate them back into feelings, they become easy to think about.

The first one, Largest Contentful Paint, asks: how long until the main thing shows up? Not the spinner, not the background color, not the little logo in the corner. The main thing. The hero image, the headline, the product photo. LCP is a formalization of the moment when a visitor’s brain says “okay, the page is here.” Google draws a line at 2.5 seconds for a good experience, which sounds arbitrary until you sit and count it out. Two and a half seconds of staring at an incomplete page is a long time. Count it. One. Two. You’re already annoyed.

The second one used to be called First Input Delay and is now Interaction to Next Paint, which asks a different question: when the visitor does something, how long until the page visibly reacts? You tap a menu. Does it open now, or in a beat? You click “add to cart.” Does the button acknowledge you? A page can render beautifully and still fail here, because rendering and responding are different jobs, and a browser busy chewing through JavaScript can’t do the second one. INP is the measurement of that specific betrayal: the page that looks ready but isn’t listening. Humans are exquisitely sensitive to this. We forgive a page that’s visibly still loading. We don’t forgive one that ignores us.

The third, Cumulative Layout Shift, is my favorite, because it measures something almost moral: does the page hold still? You’ve experienced the failure. You’re reading a paragraph and an ad loads above it and shoves everything down. You go to tap a link and at the last instant a banner appears and you tap the banner instead. CLS adds up how much the page’s contents jump around while loading. The classic causes are images without declared dimensions, so the browser doesn’t reserve space for them and reflows everything when they arrive, and content injected at the top of the page after the rest has rendered. The fix is usually to tell the browser, in the HTML, how big things will be before they load. Reserve the seat, then fill it.

Notice what all three have in common. None of them measures how fast your server is, or how many kilobytes you ship, or any of the things engineers naturally measure because they’re easy to measure. They measure moments in a human’s experience: when did I see the thing, did it respond when I touched it, did it hold still. This was a genuinely good idea. For years, performance metrics measured what was convenient for machines, and sites gamed them by getting technically fast in ways that didn’t feel fast. Measuring the felt experience is harder, and it’s the right thing to measure.

It also explains why lab tests and reality disagree. You can run a testing tool from a data center and get lovely numbers, while your actual visitors, on mid-range phones over cellular connections, have a rougher time. Google’s ranking systems care about what real Chrome users experience in aggregate, not what your test rig experienced once. This is humbling but fair. Your site’s speed is not a property of your site alone. It’s a property of your site meeting your actual audience’s actual devices.

The practical consequence of the plain-English translation is that you can diagnose most problems by watching a page load once, slowly, and asking the three questions like a checklist of feelings. Did I wait too long for the main thing? Usually a heavy image or slow server. Did the page ignore my tap? Usually too much JavaScript doing too much work at the wrong time. Did things jump? Usually missing image dimensions or late-arriving banners. When I built GazeSite to audit pages, I found that loading a page in a real browser and capturing what actually happens on the wire tells you most of the story, because these are not exotic bugs. They are the same handful of mistakes, made everywhere, mostly because nobody watched their own page load the way a stranger does.

One caution. Core Web Vitals are worth fixing, but they’re a floor, not a ceiling. Passing all three thresholds means your page has stopped actively irritating people. It says nothing about whether the page is clear, persuasive, or worth reading. I’ve seen sites with perfect vitals and no discernible reason to exist. Treat the vitals the way you’d treat spelling in an essay: mandatory, unremarkable when right, damning when wrong, and not the point. The point is what the page says. The vitals just make sure people stick around long enough to hear it.