Core Web Vitals: How to Fix LCP, INP, and CLS in 2026

Core Web Vitals measure three things: how fast your page loads (LCP), how responsive it is to interaction (INP), and how stable the layout is (CLS). Together, they represent Google’s attempt to quantify user experience as a ranking signal.

I will be direct: CWV is a tiebreaker, not a game-changer. You will not jump from page 5 to page 1 by improving your LCP from 4 seconds to 2. But when you are competing against sites with similar content and authority for positions 1-5, page experience tips the scale. And in 2026, with INP replacing FID as the responsiveness metric, many sites that previously passed now fail.

Here is how to diagnose and fix each metric with specific, actionable steps, real before-and-after examples, and the exact tools and code you need.

Real Before-and-After: WordPress eCommerce Site

Before diving into individual metrics, here is a real example that shows what is possible. A WordPress WooCommerce site selling outdoor gear came to us with these field scores (CrUX data from PageSpeed Insights):

• LCP: 4.2 seconds (poor, red)
• INP: 380ms (poor, red)
• CLS: 0.24 (poor, red)

After 6 weeks of optimization, their field scores improved to:

• LCP: 1.8 seconds (good, green) – achieved by switching hero images to AVIF format, adding fetchpriority="high", preloading the critical font, and migrating from shared hosting to Cloudways (DigitalOcean 2GB droplet)
• INP: 145ms (good, green) – achieved by replacing jQuery-heavy product filters with vanilla JavaScript, deferring WooCommerce cart fragment loading, and removing two conflicting slider plugins
• CLS: 0.04 (good, green) – achieved by adding explicit width/height to all product images, reserving space for the cookie consent banner, and applying font-display swap with size-adjust

The ranking impact: 14 product category pages moved from positions 8-15 to positions 3-7 within 45 days of passing CWV in field data. Organic traffic to those pages increased 38%.

Largest Contentful Paint (LCP): Make It Load Fast

LCP measures when the largest visible content element finishes rendering. Usually this is your hero image, video thumbnail, or a large text block.

How to Diagnose

Open Chrome DevTools > Performance panel > Record a page load. The LCP element is marked in the timeline. Also check PageSpeed Insights for field data (real user metrics from CrUX) vs lab data. Focus on field data, that is what Google actually uses for rankings.

You can also identify your LCP element programmatically by pasting this into the browser console:

new PerformanceObserver((list) => {
  const entries = list.getEntries();
  const lastEntry = entries[entries.length - 1];
  console.log('LCP element:', lastEntry.element);
  console.log('LCP time:', lastEntry.startTime);
}).observe({type: 'largest-contentful-paint', buffered: true});

Fix 1: Optimize the LCP Element

• If it is an image: Convert to WebP or AVIF (AVIF is 30-50% smaller than WebP). Compress aggressively using ShortPixel, Imagify, or the command-line tool cwebp. Add fetchpriority="high" to the hero image. Set explicit width and height attributes. Do NOT lazy-load the LCP image, that makes it slower.
• If it is text: Ensure fonts load fast. Add this to your CSS for every custom font:

@font-face {
  font-family: 'YourFont';
  src: url('/fonts/yourfont.woff2') format('woff2');
  font-display: swap;
  /* size-adjust prevents layout shift when font loads */
  size-adjust: 105%;
}

Then preload the critical font file in your HTML head:

<link rel="preload" href="/fonts/yourfont.woff2" as="font"
      type="font/woff2" crossorigin>

• If it is a video: Use a static poster image and lazy-load the video player. The poster image becomes your LCP element, which loads much faster than a video.

Fix 2: Eliminate Render-Blocking Resources

• Defer non-critical CSS: Extract above-the-fold styles into an inline <style> block, then load the full stylesheet asynchronously with media="print" onload="this.media='all'"
• Defer JavaScript with async or defer attributes. Use defer for scripts that depend on DOM order, async for independent scripts.
• Move third-party scripts (analytics, chat widgets, ads) below the fold or load them on user interaction. For example, delay Intercom or Drift chat until the user scrolls or moves their mouse.

Fix 3: Improve Server Response Time (TTFB)

Time to First Byte directly impacts LCP. If your server takes 1.5 seconds to respond, your LCP cannot possibly be under 2.5 seconds. Here is how hosting choice impacts TTFB based on our testing across 40+ client sites:

• Shared hosting (GoDaddy, Bluehost basic): 800ms-2,000ms TTFB. Unacceptable for CWV. We have never seen a site on shared hosting pass LCP consistently.
• Managed WordPress (SiteGround GoGeek, Flywheel): 300-600ms TTFB. Acceptable for most sites with proper caching.
• VPS/Cloud (Cloudways on DigitalOcean, Vultr, or AWS Lightsail): 150-400ms TTFB. Good baseline. This is what we recommend for most business sites.
• CDN-backed hosting (Cloudflare Pages, WP Engine with their CDN, Kinsta): 50-200ms TTFB globally. Ideal for sites with international audiences.
• Edge/static (Netlify, Vercel, or Cloudflare Workers): 20-80ms TTFB. The gold standard, but only works for static or JAMstack sites.

Add server-side page caching (Redis or Memcached object caching plus full-page caching through a plugin like WP Super Cache or W3 Total Cache). On WordPress, this alone can reduce TTFB from 800ms to under 200ms.

Interaction to Next Paint (INP): Make It Feel Responsive

INP replaced First Input Delay (FID) in March 2024 and is significantly harder to pass. While FID only measured the first interaction, INP measures the worst interaction throughout the entire session. Your site might respond instantly to the first click but lag on the tenth, and INP catches that.

Common INP Killers

• Long JavaScript tasks: Anything blocking the main thread for more than 50ms causes lag. Break long tasks into smaller chunks using setTimeout or requestIdleCallback.
• Heavy event handlers: Scroll listeners, input handlers, and click handlers that trigger expensive DOM operations.
• Third-party scripts: Analytics, A/B testing tools (Optimizely, VWO), live chat (Intercom, Drift), and social widgets often block the main thread for 200-500ms.
• React/Vue hydration: Client-side framework hydration can block interaction for seconds on complex pages. Consider partial hydration or server components.

INP Debugging Walkthrough Using Chrome DevTools

Here is the exact step-by-step process we use to find and fix INP issues:

1. Open Chrome DevTools (F12 or Cmd+Option+I on Mac) and go to the Performance panel.
2. Click the Record button (circle icon in top-left), then interact with your page. Click buttons, open menus, type in search boxes, scroll, use filters. Spend 15-20 seconds doing everything a real user would do.
3. Stop recording. In the timeline, look for the “Interactions” track (you may need to expand it). Each interaction shows a colored bar indicating the processing time.
4. Click on any interaction that shows a long duration (200ms+). The bottom panel will show you exactly what JavaScript ran during that interaction.
5. Look for “Long Tasks” in the Main thread track, shown as red-striped blocks. Click on them to see the call stack and identify which script or function caused the delay.
6. Check the “Event Processing” breakdown. INP has three phases: Input Delay (time before handler runs), Processing Time (handler execution), and Presentation Delay (time to render the visual update). This tells you where to focus your fix.

Common findings from this process: a WooCommerce “Add to Cart” button triggering a cart fragment AJAX call that blocks the main thread for 350ms, or a mega menu opening that forces a synchronous reflow across 200+ menu items.

How to Fix INP Issues

• Use requestAnimationFrame for visual updates instead of synchronous DOM manipulation
• Debounce input handlers: Do not process every keystroke. Wait 150-300ms after the user stops typing.
• Move heavy computation to Web Workers (off the main thread entirely)
• Implement content-visibility: auto in CSS for off-screen content sections, which tells the browser to skip rendering them until needed
• Lazy-load non-essential JavaScript until user interaction triggers it. For example, do not load the checkout script on product listing pages.
• Replace jQuery animations with CSS transitions or the Web Animations API, which run on the compositor thread instead of the main thread

Common WordPress Plugin Conflicts That Hurt CWV

Through auditing hundreds of WordPress sites, we have identified specific plugins that consistently cause CWV failures:

• Elementor (without optimization): Loads 300-500KB of CSS and JS on every page, even pages not built with Elementor. Fix: Use “Improved Asset Loading” in Elementor settings (enabled since v3.0) and use a plugin like Asset CleanUp to dequeue unused Elementor assets per page.
• Slider Revolution: Adds 150-250KB of JavaScript and causes LCP delays of 1-3 seconds. Fix: Replace with a lightweight alternative like Splide.js, or limit the slider to only pages where it actually appears.
• Contact Form 7: Loads its CSS and JS on every page, not just pages with forms. Fix: Use Conditional Loading via Asset CleanUp or add a simple functions.php snippet to dequeue CF7 assets except on contact pages.
• WooCommerce Cart Fragments: Runs an AJAX call on every page load to update the cart widget, adding 300-800ms to interaction readiness. Fix: Disable cart fragments on non-shop pages with the Disable Cart Fragments plugin or a custom snippet, then use a static mini-cart that updates on click.
• Jetpack (full suite): Loads multiple modules and external connections. Fix: Disable unused modules or switch to individual lightweight alternatives (e.g., use a dedicated image CDN instead of Jetpack’s Site Accelerator).
• Multiple caching/optimization plugins conflicting: Running WP Rocket alongside W3 Total Cache or LiteSpeed Cache creates duplicate optimization attempts that break pages. Pick one caching solution and stick with it.

Cumulative Layout Shift (CLS): Stop the Page From Jumping

CLS measures unexpected layout shifts. When a user is about to tap a button and the page shifts, causing them to tap something else, that is a CLS problem. It is also the easiest metric to fix.

Common CLS Causes and Fixes

• Images without dimensions: Always include width and height attributes. The browser reserves space before the image loads. In WordPress, this is automatic in core since version 5.5, but many themes and page builders override it.
• Web fonts causing text reflow: Use font-display: swap combined with size-adjust and ascent-override for font metric overrides. This makes the fallback font occupy the same space as the custom font, preventing shift when the font loads:

@font-face {
  font-family: 'CustomFont';
  src: url('/fonts/custom.woff2') format('woff2');
  font-display: swap;
  size-adjust: 108%;
  ascent-override: 90%;
  descent-override: 22%;
  line-gap-override: 0%;
}

• Dynamic content above the fold: Ads, cookie banners, and notification bars that push content down. Reserve space with min-height on the container. For cookie consent banners, use a bottom-anchored design instead of a top bar that shifts everything down.
• Late-loading embeds: YouTube videos, Google Maps, and social widgets. Set explicit container dimensions with aspect-ratio: aspect-ratio: 16/9; on the wrapper div before the embed loads.
• Injected content from A/B testing tools: Tools like Optimizely and Google Optimize inject DOM changes after page load, causing shifts. Use server-side A/B testing where possible, or apply the anti-flicker snippet correctly.

Testing and Monitoring: The Right Tools

Lab Tools (Test Environment)

• PageSpeed Insights: Shows both lab and field data. Field data is what Google actually uses for rankings. Lab data helps identify specific issues.
• Chrome DevTools Lighthouse: Run directly in your browser. Use the “Performance” category with mobile emulation for the most relevant scores.
• WebPageTest (webpagetest.org): Advanced testing with filmstrip view, waterfall charts, and multi-step testing. Test from multiple locations to see CDN impact.

Field Tools (Real User Data)

• Google Search Console: Core Web Vitals report shows which URL groups pass or fail across your entire site. This is the data Google uses for ranking decisions.
• Chrome UX Report (CrUX): Real user data aggregated over 28 days. The source of truth. Access via PageSpeed Insights or the CrUX API.
• Web Vitals Chrome Extension: Shows CWV metrics in real-time as you browse your site. Useful for quick checks during development.
• web-vitals JavaScript library: Add Google’s web-vitals npm package to your site to send real user CWV data to your analytics platform. This gives you field data segmented by page, device, and connection speed.

Setting Up Ongoing Monitoring

Do not just fix CWV once and forget about it. Plugin updates, new content, and design changes can introduce regressions. Set up automated monitoring:

• Schedule weekly Lighthouse CI runs in your deployment pipeline
• Set up CrUX API alerts for when any metric crosses the “needs improvement” threshold
• Monitor the Search Console CWV report monthly as part of your technical SEO maintenance
• Test CWV impact before deploying major site changes (new themes, plugin updates, redesigns)

Quick Wins Checklist: Do These First

If you want the fastest CWV improvements with the least effort, tackle these in order:

1. Add explicit width and height to all images (fixes CLS, 5 minutes per page)
2. Add fetchpriority="high" to your hero/LCP image and remove lazy-loading from it (fixes LCP, 2 minutes)
3. Enable a caching plugin like WP Super Cache or WP Rocket (fixes TTFB/LCP, 15 minutes)
4. Add font-display: swap to all @font-face rules (fixes LCP and CLS, 10 minutes)
5. Defer non-critical JavaScript by adding the defer attribute to script tags (fixes INP and LCP, 20 minutes)
6. Audit and remove unused plugins, especially sliders, social sharing widgets, and anything that loads assets on every page (fixes all three metrics, 30 minutes)
7. Preconnect to critical third-party origins like Google Fonts, your CDN, and analytics (fixes LCP, 5 minutes)

Our technical SEO team monitors CWV across all client sites and addresses regressions before they impact rankings. We typically see measurable CWV improvements within the first 2 weeks of engagement.