Core Web Vitals Explained: LCP, INP and CLS (2026)

Core Web Vitals are three metrics Google uses to measure real-world user experience: Largest Contentful Paint (loading), Interaction to Next Paint (responsiveness), and Cumulative Layout Shift (visual stability). They are part of Google's page experience signals, which means a slow, janky page can quietly hold back pages that otherwise deserve to rank.

The numbers are collected from actual Chrome users, not a lab simulation, and Google publishes them in the Chrome User Experience Report. This guide explains what each metric measures, the exact thresholds, why they matter for SEO, and concrete ways to fix each one.

What are the three Core Web Vitals?

Each metric covers a different part of how a page feels to use. A page can pass one and fail another, so you treat them as three separate problems.

Google judges your page on the 75th percentile of real visits. So if three out of four people get a good LCP but the slowest quarter sees 5 seconds, you fail. The slow tail counts.

INP replaced FID in March 2024

If you read an older performance article, you'll see First Input Delay (FID) listed as the responsiveness metric. That changed. In March 2024, Google retired FID and made Interaction to Next Paint the official Core Web Vital.

The reason is simple. FID only measured the delay before the browser started processing your first click. It ignored everything after, including the time to actually run the code and paint the result. INP measures the full round trip, for every interaction on the page, not just the first one. It is a much harsher and more honest number, which is why plenty of sites that comfortably passed FID now fail INP.

Why do Core Web Vitals matter for SEO?

Core Web Vitals are a confirmed Google ranking signal, but they work as a tiebreaker rather than a magic lever. Google has said relevance still wins: a slow page with the best answer can outrank a fast page with a weak one. Where Vitals decide things is between pages of similar quality, which is most competitive queries.

There is a second, larger reason that has nothing to do with rankings. Slow and unstable pages lose people. A visitor who taps a button and waits 600 milliseconds for anything to happen assumes it's broken and leaves. Layout that jumps as ads load makes readers tap the wrong thing. Fixing Vitals improves conversions and bounce rate whether or not Google ever rewards you for it.

How to fix Largest Contentful Paint (LCP)

LCP is usually a large hero image, a heading, or a background image. To improve it, you need that one element to arrive faster.

• Find the LCP element first. Don't guess. Chrome DevTools and PageSpeed Insights both name the exact element, so you optimize the right thing.
• Serve images in modern formats (WebP or AVIF), sized to their display dimensions, and compressed. An oversized hero image is the most common single cause of poor LCP.
• Preload the LCP image with <link rel="preload"> so the browser fetches it early instead of discovering it late.
• Cut render-blocking resources. Inline critical CSS and defer the rest. Every blocking stylesheet and script delays the first paint.
• Use a CDN and good caching so the server responds quickly, since a slow Time to First Byte caps how fast LCP can ever be.

How to fix Interaction to Next Paint (INP)

INP is almost always a JavaScript problem. When the main thread is busy running scripts, it can't respond to a tap, so the screen freezes for a moment.

• Break up long tasks. Any script that runs for more than 50 milliseconds blocks input. Split heavy work into smaller chunks and yield back to the browser.
• Defer non-essential JavaScript. Analytics, chat widgets, and third-party tags rarely need to run during the first interaction. Load them late.
• Reduce the work each interaction triggers. Avoid forcing layout recalculations on every click and keep event handlers lean.
• Audit third-party scripts. Tag managers and embeds are a frequent INP culprit because you don't control how much main-thread time they consume.

How to fix Cumulative Layout Shift (CLS)

CLS is the easiest to picture: it's the page jumping while it loads. You go to tap a link, an ad loads above it, and the link slides away. To fix it, reserve space for everything before it arrives.

• Set width and height on images and videos so the browser reserves the correct space before the file loads.
• Reserve space for ads and embeds with a fixed container, so an iframe loading later doesn't shove content down.
• Avoid inserting content above existing content. Banners and notices added at the top push everything else down and spike CLS.
• Use `font-display: optional` or preload fonts to limit the reflow when a web font swaps in for the fallback.

Measuring your Core Web Vitals

You have two kinds of data, and you need both. Lab data (Lighthouse, the lab tab in PageSpeed Insights) is repeatable and great for debugging because it's a controlled run. Field data (the Chrome User Experience Report, the same numbers Google ranks on) reflects real visitors on real devices and networks. Optimize against lab data, but confirm the win in field data, because that's what counts.

A quick way to see all three at once, with the failing element named and a fix for each, is to run your page through the UX and Core Web Vitals checker. It pulls real Chrome field data where available and falls back to a lab run so you always get a reading.

The thing to remember is that Core Web Vitals reward the same work that makes a site pleasant to use: fast loads, instant responses, and a layout that holds still. There's no trick here. Fix the experience and the metrics follow.

Want to see where your pages stand across all three Vitals plus the rest of your technical SEO? A free SEO audit checks your Core Web Vitals alongside on-page SEO, structure, and answer-readiness in about a minute, no signup required.