How to Fix Core Web Vitals: INP, LCP & CLS
Table of Contents
To fix Core Web Vitals, diagnose with real-user (field) data first, then target the specific metric that’s failing: LCP for loading, INP for responsiveness, or CLS for visual stability. You don’t optimize all three blindly—you find the one failing at the 75th percentile and fix its root cause. For most sites that metric is INP, and the fix is almost always JavaScript, not image compression.
This is the hands-on companion to the loading, responsiveness, and stability checks in a full technical SEO audit. Below: how to read the data, the highest-impact fix for each metric, and how to make improvements stick.
Core Web Vitals at a glance
Three metrics, each measuring a different part of the experience. To pass, at least 75% of real visits to a URL group must hit “Good” on all three.
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Loading | ≤ 2.5s | 2.5–4s | > 4s |
| INP (Interaction to Next Paint) | Responsiveness | ≤ 200ms | 200–500ms | > 500ms |
| CLS (Cumulative Layout Shift) | Visual stability | ≤ 0.1 | 0.1–0.25 | > 0.25 |
Diagnose with field data first
Google ranks on field data—real Chrome users, reported at the 75th percentile—not the lab score from a single test run. So start in the Search Console Core Web Vitals report or the field section of PageSpeed Insights, and find which metric is failing on which URL group. Then use the lab tools (Lighthouse, DevTools) to work out why and to verify each fix.
Once you know what’s failing, here’s where the biggest wins usually come from:
| Metric | Most common cause | Highest-impact fix |
|---|---|---|
| LCP | Heavy hero image/font or slow server response | Preload the LCP asset; compress and right-size media; cut TTFB |
| INP | Too much JavaScript blocking the main thread | Break up long tasks, defer non-critical JS, cut third-party scripts |
| CLS | Images, embeds, or ads with no reserved space | Set width/height or aspect-ratio; reserve space; font-display: swap |
Fix LCP: loading
LCP is the time until the largest visible element—usually the hero image or headline—finishes rendering. Target: under 2.5 seconds at the 75th percentile. The usual culprits are a heavy hero asset, a slow server, or render-blocking CSS and JavaScript delaying the paint.
The fixes, roughly in order of impact:
- Find the LCP element. PageSpeed Insights and DevTools name it. Optimize that element—don’t guess.
- Preload it and prioritize it. Add a
<link rel="preload">for the hero image or critical font, and setfetchpriority="high"on the LCP image. - Right-size the media. Serve modern formats (WebP/AVIF), compress, and size to the actual display dimensions. Never lazy-load the hero image.
- Cut TTFB. Add page caching and a CDN, and reduce server work so the document arrives faster.
- Remove render-blocking resources. Inline critical CSS, defer the rest, and defer non-critical JavaScript.
- Tame web fonts. Preload key fonts, limit weights, and use
font-display: swapso text isn’t invisible while a font loads.
Fix INP: responsiveness
INP measures how quickly the page responds across every interaction—taps, clicks, key presses—not just the first. It replaced FID in 2024 and is the Core Web Vital most sites fail, with reports putting the failure rate above 40%. Target: 200ms or less. The cause is almost always JavaScript hogging the main thread.
The fixes, roughly in order of impact:
- Break up long tasks. Anything over ~50ms blocks input. Split heavy work into smaller chunks and yield to the main thread between them so the browser can paint.
- Audit third-party scripts ruthlessly. Chat widgets, heavy tag managers, A/B tools, and analytics are frequent INP killers. Remove what you don’t need; lazy-load or load-on-interaction the rest.
- Defer non-critical JavaScript. Ship less on first load; load features when they’re actually used.
- Lighten event handlers. Debounce input handlers and move heavy computation off the critical path (web workers,
requestIdleCallback). - Give instant feedback. Show a pressed or loading state the moment someone interacts, so the next paint happens fast even if work continues behind it.
- Simplify the DOM. A smaller, flatter DOM is cheaper to update on every interaction.
Fix CLS: visual stability
CLS measures how much the layout jumps around as the page loads. Target: 0.1 or less. It’s usually the most straightforward Vital to fix because the causes are concrete: elements that load without reserved space and shove everything else down.
The fixes:
- Set dimensions on everything. Add explicit
widthandheight(or CSSaspect-ratio) to images, videos, and iframes so the browser reserves space before they load. - Reserve space for dynamic content. Give ad slots, embeds, and lazy-loaded modules a
min-heightor placeholder so nothing reflows when they arrive. - Stop banners from pushing content. Cookie notices, promo bars, and “back in stock” messages should sit in pre-reserved space or overlay the page—not shift it down on load.
- Reduce font reflow. Preload key fonts and use
font-display: swap; match the fallback’s metrics withsize-adjustwhere you can. - Animate the right properties. Use
transformandopacityrather than properties that trigger layout.
Re-measure and hold the line
- Confirm in the lab immediately. Re-run PageSpeed Insights or Lighthouse right after deploying so you know the change worked technically.
- Expect the field data to lag. Search Console and CrUX use a rolling 28-day window of real users, so the official Core Web Vitals status can take about a month to catch up. Don’t panic-edit while you wait.
- Validate when ready. When the URL group turns “Good” in the Search Console report, use Validate Fix to confirm it.
- Prevent regressions. Set a performance budget, test key templates before each release, and keep an eye out for new third-party scripts quietly creeping back in.
Fix templates, not just pages
One template powers hundreds or thousands of URLs, so fixing the article, product, or category template moves the whole group at once. That’s the highest-leverage performance work you can do. Start with the templates behind your most-trafficked URL groups, fix them once, and the gains compound across every page that uses them.
Core Web Vitals are one phase of a wider review of crawlability, indexing, content, and conversion. If you want the full picture, work through the SEO Audit Checklist—or have us run it for you.
