Skip to content
Core Web Vitals Guide 2026: LCP, INP & CLS Explained

Core Web Vitals Guide 2026: LCP, INP & CLS Explained

4 min read

What Are Core Web Vitals?

Core Web Vitals are a set of three metrics that Google uses to measure real-world user experience on web pages. They focus on loading speed, interactivity, and visual stability. Since 2021, Core Web Vitals have been a confirmed ranking factor in Google’s search algorithm.

In 2024, Google replaced the original interactivity metric (First Input Delay) with a more comprehensive one (Interaction to Next Paint). The 2026 Core Web Vitals consist of:

  • LCP (Largest Contentful Paint) — Loading performance
  • INP (Interaction to Next Paint) — Interactivity
  • CLS (Cumulative Layout Shift) — Visual stability

Each metric has specific thresholds: good, needs improvement, and poor. Meeting the “good” threshold for all three on at least 75% of page loads is what Google considers passing Core Web Vitals.

LCP: Largest Contentful Paint

What LCP Measures

LCP measures how long it takes for the largest visible content element to render on screen. This is usually a hero image, a large text block, or a video thumbnail. It represents the point at which the user perceives the page’s main content as loaded.

LCP Thresholds

  • Good: 2.5 seconds or less
  • Needs improvement: 2.5 to 4.0 seconds
  • Poor: More than 4.0 seconds

What Causes Poor LCP

  1. Slow server response time — The server takes too long to deliver the HTML. Measured as Time to First Byte (TTFB).
  2. Render-blocking resources — CSS and JavaScript in the <head> that must be downloaded and parsed before rendering begins.
  3. Slow resource load time — The LCP element (often an image) takes too long to download.
  4. Client-side rendering — JavaScript frameworks that build the page in the browser rather than delivering server-rendered HTML.

How to Improve LCP

Optimize server response time: Use a CDN, enable caching, and optimize server-side code. Aim for TTFB under 800ms.

Preload the LCP resource: If your LCP element is a hero image, add a preload hint:

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

Optimize images: Use modern formats (WebP, AVIF), serve appropriately sized images with srcset, and enable lazy loading for below-the-fold images only (never lazy-load the LCP image).

Eliminate render-blocking resources: Inline critical CSS, defer non-critical CSS, and add async or defer attributes to JavaScript that is not needed for initial render.

Use server-side rendering: For JavaScript-heavy applications, server-side rendering (SSR) or static site generation (SSG) delivers visible content faster than client-side rendering.

INP: Interaction to Next Paint

What INP Measures

INP measures the time from when a user interacts with your page (click, tap, or key press) to when the browser displays the visual response. Unlike the old FID metric that only measured the delay before processing started, INP captures the full round trip: input delay, processing time, and presentation delay.

INP considers all interactions during the page lifecycle and reports the worst interaction (with some statistical adjustment), giving a comprehensive picture of page responsiveness.

INP Thresholds

  • Good: 200 milliseconds or less
  • Needs improvement: 200 to 500 milliseconds
  • Poor: More than 500 milliseconds

What Causes Poor INP

  1. Long JavaScript tasks — Tasks that run for more than 50ms block the main thread, preventing the browser from responding to user input.
  2. Excessive DOM size — A large DOM (over 1,400 elements) makes rendering updates expensive.
  3. Heavy event handlers — Click and input handlers that perform expensive computations synchronously.
  4. Third-party scripts — Analytics, ads, and chat widgets that compete for main thread time.
  5. Layout thrashing — Reading layout properties (like offsetHeight) immediately after making style changes forces the browser to perform synchronous layout calculations.

How to Improve INP

Break up long tasks: Split JavaScript execution into smaller chunks using requestAnimationFrame, setTimeout, or the scheduler.yield() API. Each chunk should complete in under 50ms.

Reduce DOM size: Simplify your HTML structure. Use virtualization for long lists. Remove unnecessary wrapper elements.

Defer non-essential JavaScript: Load analytics, ads, and other non-critical scripts after the page is interactive. Use requestIdleCallback or the loading="lazy" attribute for iframes.

Optimize event handlers: Move heavy processing off the main thread using Web Workers. Debounce rapid-fire events like scroll and resize.

Minimize third-party impact: Audit third-party scripts and remove those that do not provide measurable value. Load remaining third-party code asynchronously.

CLS: Cumulative Layout Shift

What CLS Measures

CLS quantifies how much visible content unexpectedly shifts during page load. When a page element moves after the user has started reading or interacting, it creates a jarring experience. CLS scores the severity of these shifts.

CLS only counts unexpected shifts. Shifts that occur in response to user interaction (like clicking a button that expands a section) are excluded.

CLS Thresholds

  • Good: 0.1 or less
  • Needs improvement: 0.1 to 0.25
  • Poor: More than 0.25

What Causes Poor CLS

  1. Images without dimensions — Images that load without explicit width and height attributes cause the layout to reflow when they render.
  2. Dynamically injected content — Ad banners, cookie consent bars, and notification banners that push content down after initial render.
  3. Web fonts causing FOUT/FOIT — When a web font loads and replaces a fallback font with different metrics, text reflows.
  4. Late-loading embeds — YouTube embeds, maps, and social media widgets that load asynchronously and push content around.

How to Improve CLS

Always set image dimensions: Include width and height attributes on <img> and <video> elements so the browser reserves space before the resource loads:

<img src="photo.webp" width="800" height="450" alt="Description">

Reserve space for ads and embeds: Use CSS aspect-ratio or min-height to reserve space for elements that load dynamically:

.ad-slot {
  min-height: 250px;
}

Optimize font loading: Use font-display: swap with a well-matched fallback font. Tools like fontaine can generate fallback fonts with adjusted metrics to minimize layout shift.

Add content above the fold carefully: Never inject banners or notifications above existing content. Instead, use sticky overlays or place them below the current viewport.

Use CSS contain property: For elements that change size independently, use contain: layout to prevent their changes from affecting the rest of the page.

How to Test Core Web Vitals

Field Data (Real Users)

Field data reflects what actual users experience and is what Google uses for ranking:

  • Google Search Console — The Core Web Vitals report shows field data for your entire site, grouped by status.
  • PageSpeed Insights — Enter a URL to see field data from the Chrome User Experience Report (CrUX) alongside lab data.
  • Chrome UX Report — Direct access to the CrUX dataset via BigQuery or the CrUX API.

Lab Data (Simulated)

Lab data is useful for debugging because it is reproducible:

  • Lighthouse — Built into Chrome DevTools (Audits tab). Provides LCP, CLS, and performance scores with specific improvement recommendations.
  • WebPageTest — Advanced testing with filmstrip views, waterfall charts, and multi-location testing.

Continuous Monitoring

Use Real User Monitoring (RUM) tools like the web-vitals JavaScript library to collect Core Web Vitals data from every visitor:

import { onLCP, onINP, onCLS } from 'web-vitals';

onLCP(console.log);
onINP(console.log);
onCLS(console.log);

This lets you track performance trends and catch regressions before they affect your search rankings.

Core Web Vitals and SEO

Core Web Vitals are a confirmed Google ranking factor, but they are one signal among many. Content relevance, backlinks, and search intent alignment still carry more weight. Where Core Web Vitals make the biggest difference is in competitive scenarios: when two pages are equally relevant and authoritative, the one with better Core Web Vitals may rank higher.

The indirect SEO benefits are also significant. Faster, more stable pages have lower bounce rates, higher engagement, and better conversion rates, all of which send positive user signals to Google.

Conclusion

Core Web Vitals in 2026 come down to three things: load the main content fast (LCP), respond to user actions instantly (INP), and keep the page visually stable (CLS). Each metric has clear thresholds and well-understood optimization techniques.

Start by measuring your current performance in Google Search Console and PageSpeed Insights. Use the seokit meta tag generator to ensure your pages have optimized meta tags, the schema generator to add structured data that earns rich results, and the heading analyzer to verify your content structure supports both SEO and accessibility.