Core Web Vitals, Explained Without the Jargon

Somebody sent you a report with three acronyms and a lot of red. Now you’re here.

Core Web Vitals is Google’s attempt to answer a question that used to be impossible to answer: does this website feel good to use? Not “is it technically fast” by some server benchmark, but does a real human on a real phone have a pleasant time.

Google settled on three measurements. They cover loading, responsiveness, and visual stability, and between them they describe most of what makes a website feel cheap or expensive to use.

Here’s what each one actually is, in the order you’ll encounter them.

LCP: how long until something useful appears

Largest Contentful Paint measures the time until the biggest visible element finishes rendering. Usually that’s your hero image, your main headline, or a big block of text.

It’s a proxy for a simple human question: how long did I stare at a blank screen?

Google’s threshold is 2.5 seconds or less.

The reason LCP gets picked on more than the other two is that it’s the one users consciously notice. Nobody has ever described a website as having poor cumulative layout shift, but everyone has said “this thing takes forever to load.”

What usually wrecks it, according to Google’s own breakdown of where LCP time goes, is boringly predictable. About 40% of a typical LCP is your server being slow to respond at all, and another 40% is the asset itself being too big to transfer quickly. The remaining 20% is split between the browser discovering the resource too late and something blocking the render.

So when someone tells you their site is slow, roughly four times out of five the answer is “your hosting is slow” or “your hero image is enormous.”

INP: how long until the site reacts to you

Interaction to Next Paint measures the delay between a user doing something (tapping a button, opening a menu, ticking a checkbox) and the screen visibly changing in response.

Google’s threshold is under 200 milliseconds.

This is the metric that captures the specific misery of a site that has technically loaded but doesn’t work yet. You tap the menu. Nothing. You tap it again. Still nothing. Then it opens twice.

If you’ve been reading older SEO advice, you may be looking for First Input Delay instead. FID is gone. INP became a stable Core Web Vital in 2024 and replaced it. The change mattered because FID only measured the delay before processing started, which flattered sites that responded instantly and then took another second to actually do anything. INP measures the whole round trip, which is what the user experiences.

INP problems are almost always JavaScript. Something is hogging the browser’s main thread, and until it finishes, the browser cannot draw anything. Every additional third-party script (chat widgets, popups, tracking pixels, review carousels) is another candidate.

CLS: how much the page jumps around

Cumulative Layout Shift measures how much content moves after it has already appeared.

Google’s threshold is under 0.1.

CLS is the one that produces genuine rage. You go to tap a link, an ad or an image finishes loading above it, everything slides down, and you tap something else entirely. On a checkout page, this is the difference between a sale and a customer who never comes back.

The usual causes are mundane:

• Images and video embeds without width and height attributes, so the browser doesn’t reserve space for them and has to reflow the page once they arrive.
• Web fonts that swap in after the page renders, changing the size of every piece of text.
• Banners, cookie notices, or promo bars injected at the top of the page after everything below has already been drawn.

CLS is the cheapest of the three to fix and the one most often left broken, because it doesn’t show up when you test on a fast connection with everything already cached.

The detail that changes how you read your score

Google does not grade you on your average visitor. It grades you at the 75th percentile of page loads, measured separately for mobile and desktop.

That means your site has to be good for three quarters of your visitors before Google calls it good. A site that’s quick for most people and dreadful for the slowest quarter still fails, and your average will never tell you that.

Google is also explicit that a page passes only if it meets all three targets at the 75th percentile. Two out of three is not a pass.

This is why owner testing is so misleading. You load your own site constantly, from the same device, on good internet, with every asset already cached in your browser. You are the least representative visitor your website has.

How to actually check yours

Run your site through PageSpeed Insights. Look at the top section, labeled as real-user data, not the simulated score underneath. The simulated score is a diagnostic tool. The real-user data is what Google actually has on you.

Check the mobile tab, not desktop. Google uses the mobile version of your site for indexing and ranking, so the mobile numbers are the ones with consequences.

If you have no real-user data, your site doesn’t get enough traffic for Google to have collected a sample. That’s not a failure, it just means you’re working from the simulated numbers for now.

Does this actually affect rankings?

Somewhat, and less than the people selling you speed audits imply.

Google’s position is that Core Web Vitals, as part of broader page experience, “aligns with what our core ranking systems seek to reward.” That is deliberately soft language. It is not “this is a major ranking factor.” Great content on a mediocre site still outranks thin content on a fast one.

The stronger argument for fixing this has never been rankings. It’s that companies which measured the business impact consistently found that faster sites converted better. Vodafone reported 8% more sales after a 31% LCP improvement. NDTV reported a 50% better bounce rate after halving its LCP. Agrofy Market reported a 76% reduction in load abandonment after a 70% LCP improvement.

Those are big sites reporting their own numbers, and your results will be smaller. But nobody has ever run the opposite experiment and found that slowing a website down helped.

Rankings are the side effect. People not leaving is the point.

Where to start

If you’re staring at a failing report and want the shortest path to a passing one, work in this order:

1. Fix CLS first. It’s usually a handful of missing image dimensions and it’s the fastest win available.

2. Then LCP, because it’s the one users actually perceive. Start with the hero image and your server response time.

3. Then INP, which almost always means removing scripts rather than optimizing them.

The tactical version of all of this is in how to make your website load faster, which walks through the specific fixes rather than the definitions.

And if you’d rather not become an expert in any of this, speed optimization is part of how we build, not an upsell after the fact.