How to Improve Core Web Vitals: 12 Proven LCP, INP Fixes

In 2021, Google did something it very rarely does: it told website owners exactly which performance measurements it uses as ranking signals.

Core Web Vitals, three specific metrics measuring loading speed, interactivity, and visual stability, were officially confirmed as ranking factors. Pages failing these benchmarks face a structural ranking disadvantage that content quality and backlinks cannot fully overcome.

The good news: most Core Web Vitals failures trace back to a small number of fixable causes. And because they are almost always template-level problems, fixing one CSS file or one JavaScript dependency can move hundreds of pages from Poor to Good in a single deployment.

If your GSC Core Web Vitals report shows pages in Poor or Needs Improvement status, if your rankings are below what your content quality warrants, or if you have heard about Core Web Vitals but are unclear on what actually needs to change, this guide covers all three metrics with specific fixes for each.

What Core Web Vitals Are and Why They Matter

Core Web Vitals are three Google ranking signals measured from real Chrome user data collected over a rolling 28-day window. They are not simulated. They reflect the actual experience of people visiting your pages.

Metric	Measures	Good	Poor
LCP	Loading speed of the main content element	Under 2.5s	Over 4.0s
INP	Responsiveness to all user interactions	Under 200ms	Over 500ms
CLS	Visual stability during page load	Under 0.1	Over 0.25

INP replaced FID as a Core Web Vital in March 2024. INP is significantly more demanding: it measures responsiveness across the entire page session, not just the first interaction. Sites that easily passed FID may be failing INP, particularly JavaScript-heavy sites with multiple interactive elements.

How to Check Your Current Scores

Google Search Console Core Web Vitals report:
Experience, then Core Web Vitals. Review Mobile and Desktop separately. The most important feature: pages appear grouped by URL pattern.

One “Poor” group might say “Similar pages: 340 URLs” and represent your entire blog post template. This means the same CSS or JavaScript issue is failing on 340 pages simultaneously. Fix the template and all 340 pages move to Good in one deployment. This template-level leverage is why Core Web Vitals work produces such high ROI.

PageSpeed Insights (pagespeed.web.dev):
Shows both field data (from real Chrome users, what Google uses for rankings) and lab data (simulated, useful for immediate diagnosis). Field data is what matters for rankings. Lab data is useful for confirming technical fixes immediately after deployment, before waiting for field data to update.

How to Improve Core Web Vitals: LCP Fixes

Fix 1: Identify Your Exact LCP Element Before Optimising Anything

Many optimisation efforts fail because they target the wrong element. In Chrome DevTools: record a performance trace, find the LCP event in the timeline, click it. The element identified in the summary panel is your LCP element.

On most sites, the LCP element is the hero image or a large heading block above the fold. On some sites, it is a background image injected via CSS. On others, it is a video thumbnail. Confirm before optimising.

Fix 2: Compress and Convert Your LCP Image to WebP

The single highest-impact LCP fix for image-heavy pages. A JPEG hero image of 300KB converted to WebP at equivalent quality is typically 150 to 200KB. A 40 to 50% reduction in the file blocking your LCP event.

<picture>
  <source srcset="/hero.webp" type="image/webp">
  <img src="/hero.jpg" alt="Description" width="1200" height="600">
</picture>

Fix 3: Add a Preload Hint for the LCP Image

One line. Often produces 200 to 600ms improvement:

<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">

Place this in the HTML <head> before any other resource declarations. It pushes the LCP image to the top of the browser’s resource fetch queue before parsing begins.

Fix 4: Reduce Server TTFB to Under 200ms

TTFB is the delay from browser request to first byte of server response. A slow TTFB delays every subsequent load event, including LCP.

The highest-impact fix: page caching. An uncached WordPress page with database queries may have TTFB of 600ms to 1,200ms. The same page served from cache responds in 20ms to 80ms. WP Rocket handles this on WordPress. Cloudflare adds a CDN layer that reduces TTFB for geographically distributed visitors.

Fix 5: Eliminate Render-Blocking Resources

Render-blocking CSS and JavaScript delay the page paint. Nothing renders until they are downloaded and processed.

For JavaScript:

<script src="/analytics.js" defer></script>

Deferred scripts download in parallel with HTML parsing and execute after DOM completion. Non-critical scripts should all have defer.

For CSS: Inline critical above-the-fold styles directly in the <head>. Load the full stylesheet asynchronously after the initial paint.

How to Improve Core Web Vitals: INP Fixes

Fix 6: Find Long Tasks in Chrome DevTools

Open DevTools, Performance tab. Record a user interaction (click a button, open a dropdown). Look for long tasks in the flame chart: they appear as red-capped bars. Long tasks over 50ms block the browser from responding to user interactions.

Fix 7: Break Up Long JavaScript Tasks

async function processItems(items) {
  for (const item of items) {
    processItem(item);
    // Yield back to the browser between items
    await scheduler.yield();
  }
}

scheduler.yield() lets the browser handle pending user interactions between processing steps. The same work gets done, but the browser is not locked out during it.

Fix 8: Audit and Defer Third-Party Scripts

Third-party scripts are the most common INP failure cause on otherwise well-optimised sites. Analytics, chat widgets, A/B testing tools, advertising pixels: each adds JavaScript execution to your main thread.

Diagnose: Chrome DevTools Performance tab, record a click interaction, look for long tasks attributed to third-party domains.

Fix: defer or async all non-critical third-party scripts. For heavy embeds like chat widgets, use a facade: display a lightweight placeholder that loads the full third-party script only when the user clicks to interact.

Fix 9: Reduce DOM Size

Pages with over 1,500 DOM elements respond more slowly to interactions. PageSpeed Insights flags “Avoid an excessive DOM size.”

Fix: remove unused HTML from templates, implement virtual scrolling for long lists, defer off-screen content.

How to Improve Core Web Vitals: CLS Fixes

Fix 10: Set Explicit Dimensions on All Images

The most common CLS cause globally. When a browser does not know an image’s dimensions before it loads, it reserves no space. When the image loads, surrounding content shifts.

<!-- Causes CLS -->
<img src="product.webp" alt="Product">

<!-- Prevents CLS -->
<img src="product.webp" alt="Product" width="800" height="600">

With explicit dimensions, the browser calculates the correct aspect ratio before the image loads and reserves exact space. Even with width: 100%; height: auto in CSS, the HTML dimensions prevent CLS.

Fix 11: Reserve Space for Ads and Dynamic Content

Ad slots without defined minimum dimensions push content down when ads load:

.ad-container {
  min-height: 250px;
  min-width: 300px;
}

For video embeds and iframes:

.video-container {
  aspect-ratio: 16 / 9;
  width: 100%;
}

Fix 12: Fix Web Font Layout Shifts

Web fonts cause CLS when the fallback system font has different dimensions than the custom font. When the custom font loads, all text reflows.

Fix 1: Apply font-display: swap to your @font-face declarations.

Fix 2: Use size-adjust, ascent-override, and descent-override to match your fallback font dimensions to your custom font, eliminating the reflow:

@font-face {
  font-family: 'CustomFont';
  src: url('/font.woff2') format('woff2');
  font-display: swap;
  ascent-override: 95%;
  descent-override: 25%;
  size-adjust: 100%;
}

Fix 3: Self-host your fonts rather than loading from Google Fonts. Self-hosted fonts serve from your CDN with no external network dependency.

How Long Before Improvements Appear in GSC?

GSC Core Web Vitals field data reflects a rolling 28-day window from the Chrome UX Report. A fix deployed today will not fully appear in GSC for 4 to 8 weeks.

What to do while waiting:
Use PageSpeed Insights lab data immediately after deploying fixes. Lab scores confirm the technical fix is real before field data catches up. If lab scores improve, the fix worked. The field data will follow.

Fix duplicate content that affects which pages are in your CWV testing scope: How to Fix Duplicate Content in SEO: 5 Proven Methods

Build your post-fix improvement plan: How to Improve SEO Audit Results: 10 Proven Ranking Fixes

Full audit reference: Technical SEO Audit: 14 Proven Steps to Dominate Rankings

Frequently Asked Questions

Do Core Web Vitals directly affect my Google rankings?

Yes. Confirmed as ranking signals in 2021. They function as a tiebreaker: among pages with similar relevance and authority, better Core Web Vitals wins. In competitive niches where many pages are similar in strength, this tiebreaker applies constantly.

Which metric should I fix first?

LCP first for most sites. It is the most commonly failed metric with the clearest fix path. INP if your site is JavaScript-heavy. CLS is often the quickest to fix and should not be deferred.

Why do mobile scores differ from desktop?

Mobile devices have less CPU performance and slower networks. Tasks that complete in 30ms on desktop take 150ms or more on a mid-range mobile device. Google weights mobile CWV data heavily because it reflects the median user experience.

How long does it take to see Core Web Vitals improvements in GSC?

4 to 8 weeks for field data to fully update after deployment. Use PageSpeed Insights lab data for immediate confirmation.

Key Takeaways

Core Web Vitals are confirmed Google ranking signals measured from real user data.
Template-level fixes move hundreds of pages simultaneously. Always fix at template level first.
LCP: compress images, add preload hint, reduce TTFB, eliminate render-blocking resources.
INP: break up long tasks, defer third-party scripts, reduce DOM size.
CLS: explicit image dimensions, reserved space for ads, fix font swap shifts.
Field data takes 4 to 8 weeks to update. Use PageSpeed Insights lab scores for immediate fix verification.