Core Web Vitals Explained: LCP, INP and CLS

Open PageSpeed Insights, and the first thing it shows you is three colored numbers: LCP, INP, and CLS. Together they're called Core Web Vitals — Google's standardized way of measuring whether a page feels fast, responsive, and stable to real visitors.

If those acronyms look intimidating, don't worry. This guide explains each metric in plain English: what it measures, what scores count as good, how Google actually assesses them, and the fixes that move the numbers most.

The Quick Answer: What Core Web Vitals Are

Core Web Vitals are three performance metrics Google uses to judge real-world user experience on a page:

Why Google cares (and why you should too)

Google introduced Core Web Vitals as part of its page-experience signals: pages that feel fast get a small ranking boost, and — more importantly — visitors stay longer and convert more on fast pages. A page that passes all three vitals isn't just chasing a Lighthouse number; it's meeting a published bar that Google itself uses.

One thing to get straight early: Core Web Vitals are a tie-breaker, not a trump card. Google has said repeatedly that helpful, relevant content matters more than any performance score. Fix your vitals, but don't neglect the content.

LCP — Largest Contentful Paint (Loading)

What it measures, in plain English

LCP measures when the largest visible element on the screen finishes rendering — usually a hero image, a large banner, or a big block of headline text. It's Google's answer to "when does the page look loaded to the visitor?"

That last distinction matters. A page can technically "finish loading" in the background while the visitor still stares at a blank screen. LCP captures the moment the page appears ready — which is what the visitor actually experiences.

The thresholds

What usually becomes the LCP element

On most pages, the LCP element is an image — on mobile, industry data shows the LCP element is an image on roughly three-quarters of pages. That makes image optimization the single highest-leverage LCP fix for most sites.

Common LCP killers and quick fixes

• Slow server response. If the server takes a second just to reply, LCP can never be fast. Good hosting, caching, and a CDN are the foundation — see our guide on choosing the right hosting plan.
• Oversized hero images. Compress them, serve modern formats (WebP/AVIF), and size them to the display, not the camera resolution.
• Lazy-loading the LCP image. Lazy loading is great for below-the-fold images — but if it's applied to the hero image, it actively delays LCP. Never lazy-load your LCP element.
• Render-blocking resources. Heavy CSS and JavaScript in the <head> delay the first paint. Defer what you can.

INP — Interaction to Next Paint (Responsiveness)

What it measures, in plain English

INP measures how quickly the page responds to your taps, clicks, and key presses — the delay between you interacting and the screen visually updating. A page can load fast and still feel broken if every button press lags.

Unlike the old metric it replaced, INP looks at all interactions across the whole visit, not just the first one — and it reports the worst typical experience, so one sluggish interaction pattern can't hide behind a fast first click.

The thresholds

For context: 200ms is roughly the point where a delay starts feeling noticeable. Above 500ms, the page feels genuinely unresponsive.

INP replaced FID in March 2024 — what changed

The original responsiveness metric was FID (First Input Delay), which only measured the delay before the browser could start handling the visitor's very first interaction. A page could pass FID while every later click felt sluggish. Google replaced FID with INP in March 2024, and FID no longer counts toward the assessment. If an older guide, plugin, or report still quotes FID, it's out of date — work on INP instead.

Common INP killers and quick fixes

• Too much JavaScript. Long tasks on the main thread block interaction. Audit your scripts: remove unused ones, split large bundles, defer non-critical code.
• Heavy third-party widgets. Chat widgets, analytics, ad scripts, and social embeds are classic INP offenders. Load them lazily or after the main content.
• Unoptimized event handlers. Debounce scroll/resize handlers and avoid doing expensive work synchronously inside click handlers.
• INP needs real interactions to measure — lab tools can't fully simulate it. Use field data (Search Console) for the score and Chrome DevTools' Performance panel to debug.

CLS — Cumulative Layout Shift (Visual Stability)

What it measures, in plain English

CLS measures how much the page's layout jumps around while it loads. You know the experience: you're about to tap a link, the page shifts, and you tap an ad instead. CLS quantifies exactly that frustration.

Technically, a layout shift happens when a visible element changes position between rendered frames without being triggered by your interaction. CLS adds up all unexpected shifts during the page's life, grouped into "session windows" — a burst of shifts (like an ad loading) counts more heavily than tiny shifts spread over time.

The thresholds

CLS is unitless — it's a ratio of how far elements moved relative to the viewport. A score of 0.1 is roughly "barely noticeable"; 0.25+ is "visibly annoying."

Common CLS causes and quick fixes

• Images and embeds without dimensions. When the browser doesn't know an image's size in advance, it reserves no space — then the layout jumps when the image arrives. Always set width and height (or aspect-ratio) on images, videos, and embeds.
• Web fonts swapping. A fallback font renders, then the real font loads and everything reflows. Use font-display: swap thoughtfully and match fallback font metrics where possible.
• Late-loading ads, banners, and popups. Reserve space for dynamic content with fixed-size containers instead of letting it push content down.
• Content injected above existing content. Never insert banners or notices above content the visitor is already reading — append below, or use overlays.

How Core Web Vitals Are Actually Measured

This is the part most guides gloss over, and it's the reason so many site owners are confused when their scores don't match what they see.

Field data vs lab data — the critical difference

• Field data comes from real Chrome users visiting your page, collected through the Chrome User Experience Report (CrUX). This is the data Google actually evaluates.
• Lab data comes from a single simulated run — what Lighthouse and the top half of PageSpeed Insights show. It's useful for diagnosing problems, but it doesn't count toward your assessment.

You can score 95 in Lighthouse and still fail Core Web Vitals if real visitors on mid-range phones have a worse experience than the lab simulation.

The 75th-percentile rule — why "average" doesn't count

Google doesn't use the average. Each metric is assessed at the 75th percentile of real visits: at least 75% of experiences must meet the "good" threshold. In plain terms — if 1 in 4 of your visitors has a bad experience, the page fails, even if it looks perfect on your fast laptop.

This is also why testing on your own machine is misleading: your developer laptop on office Wi-Fi says nothing about visitors on budget phones and patchy mobile networks.

Mobile vs desktop are scored separately

Mobile scores are typically 2–3x worse than desktop — slower processors, less memory, variable networks. And since Google predominantly uses the mobile version for indexing and ranking, mobile is the score that matters most.

All three must pass

A perfect LCP doesn't rescue a page with poor INP. A page passes Core Web Vitals only when all three metrics are "good" at the 75th percentile. One red metric = the page doesn't pass.

How to Check Your Scores

PageSpeed Insights — lab + field in one place

Enter any URL at PageSpeed Insights and you get both: a simulated Lighthouse run (lab) at the top, and real-user CrUX field data below it (when enough traffic exists). The field data section is the one that counts.

Search Console — the data that counts

The Core Web Vitals report in Google Search Console shows field data for your whole site, grouped by URL patterns, over a rolling 28-day window. This is the authoritative view: it's the same data Google uses for assessment. Check mobile first — that's where most failures live.

Chrome DevTools — for debugging

For INP specifically (which needs real interactions), the Performance panel in Chrome DevTools lets you record a session, click around, and see exactly which interactions were slow and what code caused them. Pair it with the web-vitals JavaScript library for real-user monitoring on your live site.

Do Core Web Vitals Affect Google Rankings?

A ranking signal, not a penalty

Google is explicit: there is no "speed penalty." No switch drops your rankings for missing a threshold. Instead, pages with good vitals get a small positive signal in the page-experience system — think of it as a tie-breaker between two otherwise equal pages.

The bigger win: conversions and bounce rate

The ranking effect is modest; the business effect is not. Study after study shows faster pages convert better and bounce less. A visitor who waits 4 seconds for your hero image is a visitor halfway to your competitor. Treat Core Web Vitals as a conversion project that happens to help SEO, not the other way around.

Frequently Asked Questions

What are the good thresholds for Core Web Vitals in 2026?

Good means LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less — each measured at the 75th percentile of real visitors. "Needs improvement" covers LCP 2.5–4.0s, INP 200–500ms, CLS 0.1–0.25; anything worse is "poor." These thresholds have been unchanged since INP replaced FID in March 2024.

Is FID still a Core Web Vital?

No. Google replaced First Input Delay (FID) with Interaction to Next Paint (INP) in March 2024, and FID was later removed from CrUX tooling. If an old guide or plugin still shows FID, ignore it and optimize for INP.

Why does PageSpeed Insights show different scores than Search Console?

PageSpeed Insights mixes one simulated lab run with field data; Search Console shows only field data from real Chrome users over 28 days. The Search Console numbers are the ones that count for assessment. A good lab score with bad field data means real visitors are having a worse experience than the simulation.

Which metric do most sites fail?

LCP, especially on mobile. On mobile pages the LCP element is an image about three-quarters of the time — and oversized, unoptimized, or lazy-loaded hero images are the most common cause. Fixing the LCP image is usually the highest-leverage single change.

Can shared hosting cause bad Core Web Vitals?

It can contribute, especially to LCP: a slow server response (TTFB) delays everything downstream, and no amount of image optimization fixes a server that takes a second to answer. That said, most Core Web Vitals failures are front-end issues (images, scripts, layout) rather than hosting. Rule out the front-end first — but if the foundation is slow, our guide to choosing the right hosting plan explains what to look for.

How long does it take for Core Web Vitals fixes to show in Search Console?

The report uses a 28-day rolling window of field data, so improvements appear gradually as new visitor data replaces old. Don't expect the report to flip overnight — verify fixes immediately with PageSpeed Insights lab runs and DevTools, then watch the Search Console report trend over 2–4 weeks.

Is your site slow and you can't figure out why? Start with the foundation: choosing the right hosting plan explains how server response, resources, and plan limits feed into everything above — sometimes the fix isn't another plugin, it's the hosting underneath.