How to Fix Core Web Vitals in 2026LCP, CLS & INP Explained
Updated June 2026 · 9 min read
Core Web Vitals are Google's official set of real-user performance metrics. Since Google made them a direct ranking factor in 2021, failing them means your site is actively penalized in search results — regardless of how good your content is.
The three metrics are LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift), and INP(Interaction to Next Paint, which replaced FID in March 2024). Each one measures a distinct aspect of page experience, and each has a clear "Good" threshold Google uses to assess your ranking eligibility.
This guide covers what causes each metric to fail and — more importantly — exactly how to fix it.
LCP — Largest Contentful Paint
What it measures:How long it takes for the largest visible element on the page — usually a hero image, banner photo, or above-the-fold heading — to fully render. Google's threshold is under 2.5 secondsfor a "Good" score.
Common causes of slow LCP: An unoptimized hero image served without a CDN, server-side rendering that waits on database queries before sending HTML, or render-blocking scripts that delay the browser from painting anything at all.
How to fix it:
- Preload your LCP image. Add
<link rel="preload" as="image" href="/hero.webp">to your<head>. This tells the browser to fetch the hero image immediately rather than waiting to discover it in the DOM. - Use server-side rendering (SSR) or static generation. If your LCP element is rendered client-side by JavaScript, the browser has to download, parse, and execute your JS bundle before it can paint. SSR delivers the HTML pre-rendered, cutting hundreds of milliseconds.
- Serve assets from a CDN. A CDN like Cloudflare or Vercel Edge places your static assets in data centers close to your users. Round-trip latency alone can cost 300–800ms on transatlantic requests.
- Convert images to WebP or AVIF. Modern formats deliver 40–70% smaller file sizes than JPEG at equal visual quality, directly reducing download time.
Expected improvement: Fixing LCP typically moves scores from "Needs Improvement" to "Good" and can recover 10–30 Lighthouse performance points. Real-world LCP drops from 4s+ to under 1.5s are common after combining preload, SSR, and CDN delivery.
CLS — Cumulative Layout Shift
What it measures: How much visible content unexpectedly shifts position while the page loads. A score under 0.1is "Good." Even a score of 0.25 is noticeable to users — elements jump around as they try to click or read.
Common causes: Images without explicit width and height attributes, ads or embeds injected above the fold after initial render, web fonts causing text to reflow as they swap in, and dynamically inserted banners or cookie consent widgets.
How to fix it:
- Always set image dimensions. Add
widthandheightattributes to every<img>tag. This lets the browser reserve the correct space before the image loads, eliminating the most common source of layout shift. - Avoid inserting content above the fold after load. Banners, GDPR notices, and chat widgets loaded asynchronously push existing content down. Reserve space for them with a fixed-height container, or load them in a non-shifting overlay.
- Use
font-display: optionalorswapcarefully.swapcauses a FOUT (flash of unstyled text) that shifts layout.optionalprevents the swap but may show the fallback font permanently on slow connections. Preloading critical fonts eliminates the tradeoff entirely. - Specify aspect ratios on video and embed containers. Use the CSS
aspect-ratioproperty or the classic padding-top trick so the browser reserves proportional space before the embed loads.
Expected improvement: Sites with CLS issues above 0.25 routinely fix down to below 0.05 by setting image dimensions and removing above-fold dynamic injections. This also directly improves user experience metrics like bounce rate and session depth.
INP — Interaction to Next Paint (formerly FID)
What it measures:How quickly the page responds when a user clicks, taps, or types. INP measures the end-to-end delay from user interaction to the next visual update. Google's "Good" threshold is under 200 milliseconds.
Why this matters: FID only measured the delay before the browser started processing an event. INP measures the full response time including rendering. Sites that passed FID comfortably may now fail INP because of expensive event handlers or slow re-renders triggered by JavaScript frameworks.
Common causes: Long-running JavaScript tasks that block the main thread, heavy React re-renders triggered by simple interactions, synchronous DOM operations inside event handlers, and third-party scripts (analytics, A/B testing tools) executing during user interactions.
How to fix it:
- Reduce JavaScript execution time.Use Chrome DevTools' Performance panel to record an interaction and identify long tasks (red triangles above 50ms). Break up long synchronous work with
setTimeoutor the Scheduler API (scheduler.yield()) to give the browser time to paint between chunks. - Code-split aggressively. Use dynamic
import()to load components, modals, and heavy libraries only when they're needed. In React, wrap lazy-loaded components inSuspense. In Next.js, usenext/dynamicwithssr: falsefor client-only widgets. - Audit third-party scripts. Tag managers, chat widgets, and ad scripts are frequent offenders. Load them with
deferor move them to a Web Worker using Partytown to keep the main thread free for user interactions. - Debounce expensive handlers. Input, scroll, and resize events can fire hundreds of times per second. Debouncing or throttling these handlers prevents main-thread congestion.
Expected improvement:Sites with INP above 500ms (the "Poor" threshold) can usually reach sub-200ms by eliminating long tasks and deferring third-party scripts. Perceived responsiveness improves dramatically even before the official score threshold is reached.
Summary: Core Web Vitals at a Glance
| Metric | Good threshold | Top fix | Impact |
|---|---|---|---|
| LCP | < 2.5s | Preload hero image + CDN | High |
| CLS | < 0.1 | Set image dimensions | Medium–High |
| INP | < 200ms | Code-split + defer JS | High |
Passing all three Core Web Vitals signals to Google that your site delivers a genuinely good user experience — which is exactly what the ranking algorithm rewards. Sites that move from "Poor" to "Good" across all three metrics routinely see measurable organic ranking improvements within 4–8 weeks of the changes being indexed.
For French-language SEO content to pair with your technical fixes, check out RankChef.
Run your free Core Web Vitals audit with ARIA
Stop guessing which metric is hurting your rankings. ARIA runs a real Lighthouse audit on your site in under 30 seconds and pinpoints your exact LCP, CLS, and INP issues — ranked by impact — so you know exactly where to start. No signup required.
Run my free Core Web Vitals audit →