Core Web Vitals, Explained Simply

"Make your site faster" is the vaguest advice in SEO. Core Web Vitals turn it into three specific numbers you can actually measure, and Google publishes exactly what counts as good. This page explains what each one measures and what typically causes a bad score.

The three numbers

Core Web Vitals are Google's three measurements of what a page feels like to use. Each has a published threshold for "good".

LCP — Largest Contentful Paint. How long until the biggest thing on screen appears, usually the main image or headline. It answers "did this page load?". Good is 2.5 seconds or less.

INP — Interaction to Next Paint. When someone taps or clicks, how long before the page visibly responds. It answers "is this page reacting to me?". Good is 200 milliseconds or less. INP replaced an older metric called FID in March 2024, so guides written before then name the wrong thing.

CLS — Cumulative Layout Shift. How much the content jumps around while loading. You have met this one: you go to tap a link, an advert loads above it, everything slides down, and you tap the wrong thing. It answers "is this page holding still?". Good is 0.1 or less — it is a ratio, not a time.

How the score is actually decided

Two things surprise people here.

First, the numbers that count come from real visitors, not from a test. Google collects anonymised timings from actual Chrome users and takes the 75th percentile — meaning three-quarters of your visitors got at least that experience. A page can score beautifully on your fast laptop and still fail, because your visitors are on phones and slower connections.

Second, tools measure two different things and it is easy to confuse them. Lab data is a simulated test run on demand — repeatable, instant, useful for debugging. Field data is the real-visitor measurement Google actually uses. When the two disagree, field data wins.

It is also worth being accurate about how much this matters for ranking. Google's own position is that page experience is one consideration among many, and that great page experience will not rescue content nobody wants. Speed is worth fixing because visitors leave slow sites, and ranking is a secondary benefit.

What to do

• Measure first, at PageSpeed Insights. It shows field data at the top and lab data below — read the field section, and check the mobile tab, not desktop.
• For bad LCP, look at the biggest image above the fold. Compress it, serve a modern format like WebP, and make sure the browser starts downloading it early.
• For bad CLS, set explicit width and height on every image and reserve space for anything that loads late — banners, embeds, adverts.
• For bad INP, the cause is almost always too much JavaScript running when the user interacts. Removing an unused script or tracker is usually the biggest single win.
• Re-measure after a change, and give it time — field data is a rolling 28-day window, so today's fix shows up over the following weeks.

Common mistakes

Chasing a score of 100. The thresholds are what matter. A page at "good" on all three is done; the effort to reach a perfect score is usually better spent on the content.

Testing on desktop and calling it fixed. Most visitors are on phones, and phone results are far harsher. Google evaluates mobile.

Treating it as a ranking cheat code. A fast page with nothing to say still has nothing to say.

Sources: Understanding page experience and Web Vitals.