Core Web Vitals Explained: LCP, INP and CLS in Plain English

What Core Web Vitals measure, which numbers count as good, and exactly what to change to fix them — with real optimisation examples.

Pavlo2 June 20268 min read

PageSpeed Insights says 97 on desktop and 41 on mobile, the Core Web Vitals report in Search Console is red, and it is not obvious what to fix first. Here are the three metrics without the jargon: what each measures, which numbers Google treats as good, what breaks them, and the order to fix them in so you do not burn a week on a change worth 0.1 seconds.

2.5s

LCP — the "good" threshold

200ms

INP — the "good" threshold

0.1

CLS — the "good" threshold

75%

of users must land inside it

What the three metrics measure

Core Web Vitals do not describe "site speed" in the abstract. They describe three specific sensations: when the main content appeared, how briskly the page answers a tap, and whether things jump around under your finger. Google scores each separately, and one red metric is enough for a URL to fail the assessment.

Metric	Good	Needs work	Poor	What the user feels
LCP	under 2.5s	2.5–4.0s	over 4.0s	The main block takes ages to appear
INP	under 200ms	200–500ms	over 500ms	Tapped it, nothing happened
CLS	under 0.1	0.1–0.25	over 0.25	Content jumped, missed the button

Thresholds are assessed at the 75th percentile of real visits over the last 28 days.

LCP: why the main block takes so long to show

LCP is the time until the largest visible element in the first viewport appears — usually a hero image, a video poster or a large heading. It is the easiest of the three to fix and the biggest early win.

Slow server response. Above 800ms TTFB, nothing downstream saves you. The cause is a heavy database query, a missing cache layer, or hosting splitting one core across 40 sites.
A giant hero image. A 2.4MB JPEG in a 900px slot is the classic. WebP or AVIF at three sizes via srcset typically removes 60–70% of the weight.
Lazy-loading above the fold. loading="lazy" on the hero defers precisely the element being measured. Use it only below the fold.
Render-blocking CSS and fonts. Every external stylesheet in <head> delays first paint. Inline critical CSS, load the rest asynchronously.
Client-side rendering. If JavaScript paints the hero after the bundle arrives, LCP equals your time to hydration. Server rendering fixes it outright.

1Measure TTFB separately. Above 800ms, fix caching and hosting first and leave images alone.
2Compress above-the-fold images to a modern format and set explicit width and height.
3Add <link rel="preload"> for the LCP image and primary font — usually 200–400ms on its own.
4Strip third-party code out of the critical path: chat, pixels, maps. Load them after first interaction.

INP: the page looks ready but will not respond

INP replaced FID and measures the delay between an action and a visible response — across every interaction in a visit, not just the first. It is the hardest of the three, because it is about the quality of your JavaScript rather than file size.

1
Find the slowest interaction
INP reports your worst case, not your typical one. It is nearly always a catalogue filter, the mobile menu or a form submit. Test those, not a click on the logo.
2
Break up long tasks
Any task over 50ms blocks the main thread, and processing a 3,000-item array inside a click handler is the usual culprit. Move the computation out, update the UI immediately, do the heavy work afterwards.
3
Kill animations that never stop
Infinite keyframes, backdrop-filter and large shadows eat frames exactly while the user scrolls. We disabled them on the mobile version of our own site, and INP improved more than from any bundle work.
4
Defer third-party scripts
A chat widget loading immediately adds 150–400ms to every interaction on a weak phone. Load it on an idle timer or after the first scroll.

LCP can be fixed with money and a CDN. INP is only ever fixed by someone sitting down and rewriting an event handler.

CLS: content jumping under your finger

CLS counts how far elements move after they appear. It is the cheapest of the three to fix, because it is almost always a question of reserved space rather than performance.

Always reserve space for

Every image: width/height attributes or an aspect-ratio rule in CSS
A fixed height for banners, sliders and ad slots — before they load
The cookie consent control: never inject it above existing content
Matching metrics for the web font and its fallback, or text jumps on swap
A skeleton instead of empty space wherever data arrives after render
Embedded video, maps and review feeds inside a fixed aspect-ratio container

/* Reserve the box before media arrives */
.hero-media {
  aspect-ratio: 16 / 9;
  width: 100%;
}

/* Font swap without the text jumping */
@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter.woff2') format('woff2');
  font-display: swap;
  size-adjust: 100%;
  ascent-override: 90%;
}

/* The ad slot exists before the ad does */
.ad-slot { min-height: 250px; }

Measuring without fooling yourself

The main trap is confusing lab data with field data. A lab run shows how a page behaves in an emulator on one load; field data shows what real users experienced. Ranking leans on the second.

Search Console, Core Web Vitals report — the only source reflecting how Google assesses your site. It groups URLs by template, so fixing one template closes hundreds of pages.
PageSpeed Insights — shows both cuts. The field-data panel at the top matters far more than the score at the bottom; do not chase the 0–100 number.
DevTools Performance with 4x CPU throttling — the only practical way to see the long tasks that ruin INP.
The `web-vitals` library on your own site — reports real values into analytics, so you see the effect next day instead of next month.
An actual budget phone. Five minutes on a $150 Android tells you more than any report. The wider process is in our page loading speed guide.

One firm position: Core Web Vitals are a lightweight ranking signal. They almost never lift weak content into the top results, but they steadily drag down a site that is otherwise fine. So structure and content first, via the SEO checklist, then the metrics — though "then" should not mean "someday".

Frequently asked questions about Core Web Vitals

How much do Core Web Vitals actually affect rankings?

They are a real but lightweight ranking signal: they will not move a page from tenth to first if the content is weaker. They work mostly as a tiebreaker between roughly equal results, and indirectly through behaviour, since slow pages collect more bounces. The clearest payoff from fixing them usually shows in conversion rather than position.

Why does PageSpeed say 95 while Search Console shows red?

Because they report different kinds of data. PageSpeed defaults to a lab run inside an emulator, while Search Console reports field data from real visitors over 28 days at the 75th percentile. If your audience uses older phones on slow connections, the lab score is far more optimistic than the truth.

How long until the report turns green after a fix?

The data uses a rolling 28-day window, so the first movement appears after about a week and the picture fully refreshes within a month. If nothing has changed after six weeks, the fix did not work on real devices or landed on the wrong page template.

What is INP and how does it differ from FID?

INP measures how long a page takes to respond visibly to every interaction during a visit and reports the worst one. FID looked only at the first interaction and only at input delay, which produced a flattering picture. INP is therefore much stricter, and fixing it means reworking JavaScript logic rather than shrinking file sizes.

Can the metrics be fixed without rebuilding the site?

Usually yes. Roughly 70% of cases close without touching architecture: compressing images, preloading key assets, deferring third-party scripts, reserving space for banners and fonts. A rebuild becomes necessary when above-the-fold content is rendered on the client or the site sits on a heavy theme with a dozen plugins.

In short

Three metrics, three sensations: LCP is content appearing, INP is responding, CLS is staying still.
Assessment uses the 75th percentile of real visits over 28 days — one quick test on your laptop proves nothing.
Fix in order: TTFB and images, then long JavaScript tasks, then reserved space.
INP is usually ruined by third-party widgets and permanent mobile animations, not bundle size.
The metrics amplify a healthy site and rescue no weak one — read them alongside your mobile experience.

Core Web Vitals
performance
SEO

WebEngine