onezlabs

0%

SEO

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

A practical guide to diagnosing and fixing Core Web Vitals failures — LCP, INP, and CLS — with specific techniques for WordPress and Next.js sites.

June 22, 202612 min read
#Core Web Vitals#LCP#INP#CLS#Page Speed#Performance#SEO
Core Web Vitals 2026: How to Pass LCP, INP, and CLS

Why Core Web Vitals Still Matter in 2026

Core Web Vitals have been a Google ranking signal since 2021, but the 2024 update that replaced FID (First Input Delay) with INP (Interaction to Next Paint) was the most significant change yet. INP is a harder metric to pass — it measures responsiveness throughout the entire user session, not just the first interaction. Many sites that were passing Core Web Vitals under the FID standard found they were failing under INP.

Beyond rankings, there is a direct business case for Core Web Vitals performance. Studies across e-commerce and lead generation sites consistently show that a 1-second improvement in page load time increases conversions by 2-7%. For a site processing ₱1,000,000 monthly, a 5% conversion improvement is ₱50,000 in additional revenue. That calculation alone justifies the investment in performance work that I include in every website speed optimization engagement.

The thresholds to target: LCP under 2.5 seconds (Good: <2.5s, Needs Improvement: 2.5–4.0s, Poor: >4.0s). INP under 200ms (Good: <200ms, Needs Improvement: 200–500ms, Poor: >500ms). CLS under 0.1 (Good: <0.1, Needs Improvement: 0.1–0.25, Poor: >0.25).

How to Measure Your Current Scores

Use three tools together for accurate diagnosis:

PageSpeed Insights (pagespeed.web.dev): Enter any URL and get both field data (real user experiences from the CrUX dataset) and lab data (simulated Lighthouse audit). The field data shows you what Google actually sees. The lab data shows specific diagnostics and opportunities. Run this on your five most important pages — not just the homepage.

Google Search Console Core Web Vitals report: Shows which pages are passing and failing based on field data, grouped by issue type. The "Poor URLs" in this report are the pages to fix first — they are already hurting your rankings.

Chrome DevTools Performance tab: For deep diagnosis of INP and LCP issues. Record a performance trace on the page, identify long tasks, and trace them back to specific scripts. This level of detail is necessary for INP optimization especially.

Fixing LCP (Largest Contentful Paint)

LCP measures when the largest visible element in the viewport (usually a hero image, H1 text, or a large card) paints. The most common cause of slow LCP is an unoptimized hero image. Here is the systematic fix process:

Step 1: Identify the LCP element. In Chrome DevTools, go to Performance tab, record a page load, and look for the "LCP" marker in the timeline. Or install the Web Vitals Chrome extension — it highlights the LCP element with a green border. Most of the time it is your hero image.

Step 2: Optimize the LCP image.

<!-- Before: unoptimized hero -->
<img src="/hero.jpg" alt="Hero image">

<!-- After: fully optimized hero -->
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">
<img
  src="/hero.webp"
  alt="Descriptive alt text"
  width="1200"
  height="630"
  fetchpriority="high"
  loading="eager"
  sizes="(max-width: 768px) 100vw, 1200px"
  srcset="/hero-400.webp 400w, /hero-800.webp 800w, /hero-1200.webp 1200w"
>

The four key changes: convert to WebP (30-50% smaller than JPEG), add a preload hint in the <head>, set fetchpriority="high" so the browser downloads it before other resources, and use loading="eager" to disable lazy loading on the LCP element.

Step 3: Reduce TTFB. If your server takes 1 second to respond, your LCP cannot be under 2.5 seconds regardless of how optimized the image is. Use Cloudflare as a CDN and proxy for instant TTFB improvements. For WordPress, enable full-page caching (WP Rocket or LiteSpeed Cache) so repeated requests serve from cache without PHP execution.

Step 4: Eliminate render-blocking resources. CSS and scripts in the <head> that are not critical for the above-the-fold content delay when the LCP element can paint. Move non-critical JavaScript to defer or async. Extract critical CSS and inline it; load the rest asynchronously.

Fixing INP (Interaction to Next Paint)

INP is the hardest Core Web Vitals metric to fix because it measures responsiveness throughout the entire user session, not just at load time. An INP failure means users are experiencing unresponsive interactions — clicking buttons that take 500ms+ to respond, typing into fields with visible lag.

Identify long tasks. In Chrome DevTools Performance tab, record a typical user session and look for tasks taking 50ms+ on the main thread — these are "long tasks" that block the browser from responding to user input. The most common culprits: heavy JavaScript executed at page load, third-party scripts (chat widgets, analytics, A/B testing tools), and React state updates that re-render large component trees.

// Diagnosing INP with the PerformanceObserver API
const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.interactionId && entry.duration > 200) {
      console.log("Slow interaction detected:", {
        type: entry.name,
        duration: entry.duration,
        startTime: entry.startTime,
        element: entry.target,
      });
    }
  }
});

observer.observe({ type: "event", buffered: true, durationThreshold: 100 });

Break up long tasks. Any synchronous work taking over 50ms should be broken into smaller chunks using setTimeout, scheduler.postTask(), or requestIdleCallback() to yield back to the browser between chunks.

Defer non-critical JavaScript. Third-party scripts are the most common source of INP failures. Load chat widgets with a setTimeout delay of 3-5 seconds after page load. Load analytics scripts with async and defer. Test the impact of each third-party script by temporarily removing them — the performance gain is often dramatic.

Fixing CLS (Cumulative Layout Shift)

CLS measures visual stability — how much content jumps around during page load. The most common causes:

Images without dimensions:

<!-- Bad: no dimensions, causes layout shift when image loads -->
<img src="/product.jpg" alt="Product">

<!-- Good: explicit dimensions reserve space before image loads -->
<img src="/product.jpg" alt="Product" width="400" height="300">

Web fonts causing FOUT/FOIT: Add font-display: swap to your @font-face declarations. Use <link rel="preload"> for critical fonts. Self-host fonts instead of loading from Google Fonts to eliminate the DNS lookup on first visit.

Ads and embeds without reserved space: Any dynamically injected content (ad banners, cookie consent bars, newsletter popups) that pushes page content down causes CLS. Reserve space for ads with explicit min-height on the container before the ad loads. Avoid injecting banners above existing content — put them in reserved containers.

Dynamically injected content: If your JavaScript adds elements above existing content after the page loads — announcements, promotional bars, notification banners — this causes CLS. Either include these in the initial HTML or inject them at the bottom of the page where they do not shift existing content.

Platform-Specific Fixes

WordPress quick wins (in priority order):

1. Install WP Rocket or LiteSpeed Cache — enables page caching, file minification, image lazy loading, and critical CSS extraction in one plugin. This single change typically improves LCP by 30-50% on most WordPress sites.

2. Set up Cloudflare (free tier) for CDN and TTFB reduction. Change your DNS nameservers, enable "Speed" features in the Cloudflare dashboard.

3. Convert all images to WebP with Imagify or ShortPixel (auto-converts on upload).

4. Disable and remove unused plugins. Every active plugin adds PHP execution time and potentially JavaScript.

5. Audit and remove or defer third-party scripts. Use WP Rocket's "Delay JavaScript Execution" feature to defer non-critical scripts by 3 seconds.

Next.js quick wins:

1. Replace all <img> tags with next/image — instant WebP conversion, lazy loading, and dimension reservation.

2. Replace all font loading with next/font — eliminates render-blocking font requests and adds font-display: swap automatically.

3. Add priority prop to the LCP image component.

4. Check for "use client" components that should be Server Components — unnecessary client components add JavaScript to the bundle and can increase INP.

5. Enable Partial Prerendering (PPR) in Next.js 15 for pages with dynamic + static content mixtures.

Core Web Vitals optimization is a key part of the technical SEO audits I run for clients. Check my project portfolio for before/after performance numbers on sites I have optimized.

Frequently Asked Questions

Do Core Web Vitals directly affect Google rankings?

Yes, Core Web Vitals are a confirmed Google ranking signal as part of the Page Experience update. However, Google has consistently said content quality and relevance outweigh page experience signals. A page with excellent content but poor Core Web Vitals will usually still rank, but will rank lower than an equivalent page with good Core Web Vitals. For competitive queries where several pages have similar content quality, Core Web Vitals can be the deciding factor.

What is the difference between lab data and field data for Core Web Vitals?

Lab data (from PageSpeed Insights Lighthouse audit, Chrome DevTools) simulates a page load in controlled conditions. Field data (Chrome User Experience Report, the 'Discover what real users experience' section in PageSpeed Insights) measures actual user experiences across all real visits. Google uses field data for rankings. Lab data is for diagnosis. A page can pass in lab conditions and fail in field data if real users have slower devices or connections.

How long does it take Core Web Vitals improvements to affect rankings?

Google refreshes Core Web Vitals data approximately every 28 days using a rolling 28-day window of field data. So improvements in real user experience take 4-6 weeks to fully reflect in ranking signals. The improvement must show up in sufficient real user visits to be statistically significant — for low-traffic pages, improvements may take longer to appear in the data.

Share:TwitterLinkedIn

Get the newsletter

Practical articles on AI development, full stack engineering, and WordPress — delivered whenI publish, not on a schedule. No spam, ever.

JO

Johnbert Oñez

AI Solutions Engineer & Full Stack Developer

Johnbert builds AI systems, web applications, and WordPress solutions for clients worldwide. Based in Davao City, Philippines. 6+ years, 50+ projects.

More Like This

Enjoyed the article? Let's build something together.

From AI chatbots to SaaS products — I turn ideas into working software. Based in Davao City, available worldwide.