Core Web Vitals 2026: Complete Guide to LCP, INP, and CLS

Q: What is a good LCP score?

A good LCP score is 2.5 seconds or less. LCP between 2.5s and 4.0s needs improvement, and above 4.0s is poor. LCP measures how quickly the largest visible content element (usually a hero image or heading) loads in the viewport. The threshold has remained 2.5s since Core Web Vitals were introduced.

Q: What is the INP threshold?

A good INP score is 200 milliseconds or less. INP between 200ms and 500ms needs improvement, and above 500ms is poor. INP measures the time from a user interaction (click, tap, key press) to when the browser presents the next visual update (next paint).

Q: How do I fix Cumulative Layout Shift (CLS)?

The most common CLS fixes are: set explicit width and height attributes on all images and videos, reserve space for ads and embeds with min-height, use the CSS aspect-ratio property for responsive media, avoid inserting content above existing content after page load, use font-display: swap or optional for web fonts, and preload critical fonts.

Q: What is the difference between lab data and field data?

Lab data is measured in a controlled, simulated environment (like Lighthouse or PageSpeed Insights lab mode) with a fixed device and network. Field data (also called Real User Metrics or RUM) comes from actual user visits collected via the Chrome User Experience Report (CrUX). Google uses field data for ranking decisions. Lab data is useful for debugging but does not reflect real-world performance.

Q: Do Core Web Vitals directly affect rankings?

Yes, but as a tiebreaker rather than a dominant signal. Google has confirmed that Core Web Vitals are part of the page experience ranking signal. When two pages have similar content quality and relevance, the one with better Core Web Vitals scores may rank higher. However, content quality and relevance remain far more important ranking factors.

Q: How can I measure Core Web Vitals for my site?

Use Google PageSpeed Insights for per-URL analysis with both lab and field data, Google Search Console Core Web Vitals report for site-wide field data trends, Chrome DevTools Performance panel for detailed lab debugging, the web-vitals JavaScript library for custom field data collection, and InstaRank SEO's page speed checker for comprehensive analysis.

1. What Are Core Web Vitals and Why They Matter for SEO

Core Web Vitals are a set of three standardized metrics that quantify real-world user experience on the web. Introduced by Google in May 2020 and incorporated into the page experience ranking signal in June 2021, these metrics measure three fundamental aspects of user experience: loading performance (how fast the main content appears), interactivity (how quickly the page responds to user actions), and visual stability (how much the layout shifts while loading).

The current three Core Web Vitals for 2026 are:

LCP (Largest Contentful Paint): Measures perceived load speed by timing when the largest content element becomes visible in the viewport. Threshold: 2.5 seconds or less.
INP (Interaction to Next Paint): Measures responsiveness by timing the delay between a user interaction and the next visual update. Replaced FID in March 2024. Threshold: 200 milliseconds or less.
CLS (Cumulative Layout Shift): Measures visual stability by quantifying how much visible content shifts unexpectedly during page load. Threshold: 0.1 or less.

Figure 1: Core Web Vitals thresholds for 2026 -- LCP, INP (replaced FID in March 2024), and CLS with good, needs improvement, and poor ranges

Important: FID is Gone

FID (First Input Delay) is no longer a Core Web Vital. Google replaced FID with INP (Interaction to Next Paint) on March 12, 2024. If you see any SEO tool or guide still referencing FID thresholds, that information is outdated. INP is a strictly better metric because it measures the full interaction duration (not just input delay) across all interactions (not just the first one).

How Much Do Core Web Vitals Affect Rankings?

Google has described Core Web Vitals as a tiebreaker signal. When two pages have similar content quality, relevance, and authority, the page with better Core Web Vitals scores may rank higher. However, content quality and topical relevance remain far more important. According to a 2024 analysis by Search Engine Journal, sites that improved their Core Web Vitals from poor to good saw an average 5-7% increase in organic traffic, with the most impact on highly competitive keywords where pages are closely matched in content quality.

Key Insight

Core Web Vitals are table stakes, not a silver bullet. Fixing a poor LCP will not outrank a competitor with a better article. But if your content is comparable, good Core Web Vitals give you an edge. Think of them as the minimum bar for a professional web presence in 2026.

2. LCP (Largest Contentful Paint) -- Loading Speed

LCP measures the time it takes for the largest visible content element in the viewport to become fully rendered. This is the metric that most closely reflects what users perceive as “the page has loaded.” The LCP element is typically a hero image, background image, or a large heading text block -- whatever takes up the most visual space above the fold.

Rating	Time	User Perception
Good	0 - 2.5 seconds	Page feels fast, content loads quickly
Needs Improvement	2.5 - 4.0 seconds	Noticeable delay, some users bounce
Poor	Above 4.0 seconds	Page feels broken, high bounce rate

Figure 2: LCP measures the largest visible content element in the viewport -- typically a hero image, video poster, or heading text

How to Optimize LCP

LCP optimization breaks down into four main areas: server response time, resource load time, render-blocking resources, and client-side rendering.

1. Reduce Server Response Time (TTFB)

Use a CDN (Content Delivery Network) to serve content from edge locations close to users
Implement server-side caching (Redis, Memcached) for database-heavy pages
Upgrade to HTTP/2 or HTTP/3 for multiplexed connections
Optimize database queries and use connection pooling
Target TTFB under 800ms (Google's recommended threshold)

2. Optimize the LCP Resource

Preload the LCP image: Add <link rel="preload" as="image" href="hero.webp"> to the <head>
Use modern formats: WebP saves 25-35% over JPEG; AVIF saves 50%+
Serve correct sizes: Use srcset and sizes attributes so mobile does not download desktop images
Set fetchpriority="high": Tell the browser to prioritize the LCP image over other resources
Do NOT lazy-load the LCP element: Lazy loading delays the most important resource

3. Eliminate Render-Blocking Resources

Inline critical CSS: Include the CSS needed for above-the-fold content directly in the HTML
Defer non-critical CSS: Load below-the-fold CSS asynchronously with media="print" onload="this.media='all'"
Defer JavaScript: Use defer or async on script tags, or move them to the end of <body>
Remove unused CSS/JS: Use Chrome DevTools Coverage tab to find and eliminate dead code

<head>
  <!-- Preload LCP image -->
  <link rel="preload" as="image" href="/hero.webp"
        fetchpriority="high" type="image/webp">

  <!-- Inline critical CSS -->
  <style>
    .hero { width: 100%; aspect-ratio: 16/9; }
    h1 { font-size: 2.5rem; font-weight: 700; }
  </style>

  <!-- Defer non-critical CSS -->
  <link rel="stylesheet" href="/styles.css"
        media="print" onload="this.media='all'">
</head>

3. INP (Interaction to Next Paint) -- Responsiveness

INP (Interaction to Next Paint) measures the time from when a user interacts with your page (click, tap, or keyboard input) to when the browser presents the next visual update. INP replaced FID (First Input Delay) as a Core Web Vital on March 12, 2024. The reason for the change was that FID only measured the delay before the first interaction was processed, not the entire interaction duration, and it only measured the first interaction, ignoring all subsequent ones.

Figure 4: INP measurement flow -- from user interaction to next visual update, covering input delay, event processing, and presentation delay

INP Thresholds

Rating	Time	User Perception
Good	0 - 200ms	Page feels instant and responsive
Needs Improvement	200 - 500ms	Perceptible delay after clicking/tapping
Poor	Above 500ms	Page feels broken, users think click failed

How to Optimize INP

INP optimization focuses on reducing the time the browser's main thread is blocked by JavaScript. The three components of INP are input delay (the time the main thread is busy when the interaction occurs), processing time (event handler execution), and presentation delay (rendering the visual update).

1. Break Up Long Tasks

Long tasks (JavaScript execution blocks lasting longer than 50ms) are the primary cause of poor INP. When the main thread is executing a long task and the user clicks, the click has to wait until the task finishes before it can be processed. The solution is to break long tasks into smaller chunks using requestAnimationFrame(), setTimeout(), or the scheduler.yield() API.

// BAD: One long task blocks the main thread
function processAllItems(items) {
  for (const item of items) {
    // Each iteration takes 10ms, 1000 items = 10 seconds blocked!
    processItem(item);
  }
}

// GOOD: Yield to the main thread between chunks
async function processAllItems(items) {
  const CHUNK_SIZE = 50;
  for (let i = 0; i < items.length; i += CHUNK_SIZE) {
    const chunk = items.slice(i, i + CHUNK_SIZE);
    for (const item of chunk) {
      processItem(item);
    }
    // Yield to let the browser handle user interactions
    await new Promise(resolve => setTimeout(resolve, 0));
  }
}

2. Reduce JavaScript Payload

Code splitting: Load only the JavaScript needed for the current page, not the entire application bundle
Tree shaking: Remove unused exports from your JavaScript bundles at build time
Lazy import: Use dynamic import() for features that are not immediately needed (modals, dropdowns, analytics)
Audit third-party scripts: Tag managers, analytics, chat widgets, and social embeds collectively add hundreds of milliseconds. Remove any that do not provide clear business value.

3. Optimize Event Handlers

Keep click/tap handlers under 50ms execution time
Move heavy computation to Web Workers (off the main thread)
Debounce scroll and resize event listeners
Use requestAnimationFrame for visual updates instead of synchronous DOM manipulation
Avoid forced layout recalculations (reading layout properties after writing to the DOM)

Pro Tip: Use scheduler.yield()

The scheduler.yield() API (available in Chrome 129+) is the recommended way to yield to the main thread in 2026. Unlike setTimeout(0), it preserves task priority so your code resumes before lower-priority tasks. Use it in long-running event handlers to keep INP under 200ms.

4. CLS (Cumulative Layout Shift) -- Visual Stability

CLS measures how much visible content shifts unexpectedly during the lifespan of a page. It quantifies the frustrating experience of trying to click a button that suddenly moves because an ad loaded above it, or reading text that jumps down because an image expanded. CLS is calculated as the sum of all individual layout shift scores that occur without user input. Each shift score is: impact fraction x distance fraction.

Figure 3: CLS before and after -- images without dimensions cause layout shifts that push content down unexpectedly

Common Causes of CLS

Images without dimensions: When an <img> tag lacks width and height attributes, the browser cannot reserve space for the image before it loads. When the image loads, it pushes all content below it downward. This is the #1 cause of CLS on the web.
Late-loading ads and embeds: Ad slots and third-party embeds (YouTube, Twitter, Instagram) often load after the initial page render, pushing content down or sideways. Reserve space with explicit min-height on container elements.
Web font loading (FOIT/FOUT): When a web font loads, the browser may swap fallback text for the web font, causing text to resize and reflow. The difference in glyph sizes between the fallback and web font causes layout shifts.
Dynamic content injection: JavaScript that inserts content above the current viewport (banners, cookie notices, notification bars) pushes existing content down.
Top-of-page banners and bars: Cookie consent banners, promotional bars, and app install banners that appear after page load and push content down.

How to Fix CLS

/* 1. Always set width and height on images */
<img src="photo.webp" width="800" height="450" alt="Description"
     loading="lazy" decoding="async">

/* 2. Use aspect-ratio for responsive images */
.hero-image {
  width: 100%;
  aspect-ratio: 16 / 9;  /* Reserves correct space */
  object-fit: cover;
}

/* 3. Reserve space for ad slots */
.ad-container {
  min-height: 250px;  /* Standard 300x250 ad */
  background: #f5f5f5;
}

/* 4. Use font-display: swap for web fonts */
@font-face {
  font-family: 'CustomFont';
  src: url('/fonts/custom.woff2') format('woff2');
  font-display: swap;  /* Show fallback immediately */
}

/* 5. Use CSS containment for dynamic content */
.dynamic-widget {
  contain: layout;
  min-height: 200px;
}

Warning: Overlay vs Layout Shift

Not all movement is CLS. Overlays (modal dialogs, tooltips, dropdowns) that appear on top of content without pushing it do NOT contribute to CLS. Only elements that change position in the document flow count. Cookie banners that overlay content are fine; cookie banners that push content down are CLS. Use position: fixed or position: absolute for banners to avoid CLS.

5. Measuring Core Web Vitals: Tools and Methods

Tool	Data Type	Metrics	Best For
PageSpeed Insights	Both lab + field	LCP, INP, CLS, FCP, TTFB	Per-URL analysis with actionable suggestions
Google Search Console	Field only (CrUX)	LCP, INP, CLS	Site-wide trends and URL grouping
Chrome DevTools	Lab only	All metrics + detailed traces	Debugging specific performance issues
Lighthouse	Lab only	LCP, CLS, TBT (proxy for INP)	CI/CD integration and benchmarking
web-vitals.js	Field (custom RUM)	LCP, INP, CLS, FCP, TTFB	Custom field data collection for your users
InstaRank SEO	Lab + analysis	LCP, CLS, performance score	SEO-focused analysis with actionable fixes

Using PageSpeed Insights Effectively

PageSpeed Insights (PSI) is the most important tool because it shows both lab data (Lighthouse simulation) and field data (CrUX real user data) for any URL. The field data section at the top shows what Google actually uses for ranking. If a URL has enough traffic, PSI shows origin-level (entire domain) and URL-level CrUX data with 28-day rolling averages. Focus on the field data -- lab data is only useful for debugging.

6. Lab Data vs Field Data (CrUX)

Understanding the difference between lab and field data is critical because they often tell different stories, and Google uses field data (CrUX) for ranking decisions, not lab data.

Aspect	Lab Data	Field Data (CrUX)
Source	Lighthouse, Chrome DevTools	Chrome User Experience Report (real users)
Environment	Simulated (fixed device, network)	Real users, real devices, real networks
INP measurement	Not available (TBT used as proxy)	Full INP measurement across all interactions
Used for ranking?	No	Yes (75th percentile)
Time period	Single point-in-time test	28-day rolling average
Best for	Debugging, testing fixes, CI/CD	Understanding real user experience

Key Insight: The 75th Percentile Rule

Google uses the 75th percentile (p75) of field data for its ranking signal. This means that 75% of your real users need to have a good experience for you to pass. A few users with bad experiences on slow devices or connections will not fail you -- but if more than 25% of your users have poor Core Web Vitals, your page fails. This is why field data is what matters, not a single lab test on a fast machine.

A common scenario: your Lighthouse lab score shows 95/100, but your CrUX field data shows poor INP. Why? Because lab tests do not simulate real user interactions (scrolling, clicking buttons, filling forms). Lab data uses TBT (Total Blocking Time) as a proxy for INP, but TBT does not capture the same thing. Always check field data in PageSpeed Insights or Google Search Console to know what Google sees.

7. 2026 Updates and What to Expect Next

What Changed Since 2024

March 2024: INP officially replaced FID as a Core Web Vital. FID is no longer reported in CrUX data or Google Search Console.
July 2024: Google completed the transition to 100% mobile-first indexing. All sites are now indexed based on their mobile version exclusively.
2024-2025: Google continued to refine how Core Web Vitals factor into the page experience signal. The emphasis shifted from simply passing thresholds to having excellent field data scores.
Chrome 129+ (2024): The scheduler.yield() API shipped, making it easier for developers to break up long tasks and improve INP.

What to Expect Going Forward

Smooth scroll metrics: Google has been experimenting with measuring scroll responsiveness as a potential future metric, capturing jank and frame drops during scrolling.
Soft navigation support: CrUX is expanding to measure Core Web Vitals for “soft navigations” (SPA client-side route changes), not just initial page loads.
Tighter thresholds: As the web improves overall, Google may tighten the “good” thresholds over time. A 2.5s LCP that is “good” today might be reclassified as “needs improvement” in the future.
New metrics: Google continuously evaluates new metrics through the Web Vitals program. Any new metric goes through an “experimental” phase before potentially replacing an existing Core Web Vital.

Stay Current

Follow the web.dev blog and the Chrome Platform Status for announcements about new metrics, threshold changes, and API updates. Changes are always announced well in advance with a transition period.

8. Frequently Asked Questions

What are Core Web Vitals and why do they matter for SEO?

Core Web Vitals are three specific metrics that measure real-world user experience on your website: LCP (loading speed, threshold 2.5s), INP (interactivity, threshold 200ms), and CLS (visual stability, threshold 0.1). Since June 2021, they have been part of Google's page experience ranking signal. Pages that pass all three thresholds on their field data (75th percentile of real users) receive a ranking advantage over pages that do not. While content quality is still the dominant ranking factor, Core Web Vitals serve as a meaningful tiebreaker for competitive keywords.

What replaced FID as a Core Web Vital?

INP (Interaction to Next Paint) replaced FID (First Input Delay) as a Core Web Vital on March 12, 2024. INP is a superior metric for three reasons: it measures the entire interaction duration (from input to next visual update), not just the initial delay; it considers all interactions during the page visit, not just the first one; and it reports the worst interaction (approximately the 98th percentile for pages with many interactions), ensuring even late interactions are responsive.

What is a good LCP score?

A good LCP score is 2.5 seconds or less, measured at the 75th percentile of real user visits. LCP between 2.5s and 4.0s needs improvement, and above 4.0s is poor. The LCP element is the largest visible content in the viewport -- typically a hero image, video poster, or large heading text. To optimize LCP: preload the LCP image, use a CDN, compress images to WebP/AVIF, inline critical CSS, defer non-critical JavaScript, and set fetchpriority="high" on the LCP element. The 2.5s threshold has been consistent since Core Web Vitals launched.

What is the INP threshold?

A good INP score is 200 milliseconds or less. INP between 200ms and 500ms needs improvement, and above 500ms is poor. INP is measured at the 75th percentile of real user visits. It captures the time from when a user clicks, taps, or presses a key to when the browser shows the resulting visual change. The most common cause of poor INP is long JavaScript tasks blocking the main thread. Fix this by breaking up long tasks, reducing JavaScript payload, code splitting, and using scheduler.yield().

How do I fix Cumulative Layout Shift (CLS)?

The most impactful CLS fixes are: (1) Set explicit width and height attributes on all <img> and <video> elements so the browser reserves space before loading. (2) Use the CSS aspect-ratio property for responsive media. (3) Reserve space for ads and third-party embeds with min-height. (4) Use font-display: swap or optional for web fonts. (5) Avoid dynamically inserting content above the user's current viewport position. (6) Use position: fixed for notification bars and cookie banners instead of pushing content down.

What is the difference between lab data and field data?

Lab data is collected in a controlled, simulated environment (like Lighthouse or PageSpeed Insights lab mode) with a fixed device profile and network speed. Field data (also called Real User Metrics or RUM) is collected from real Chrome users through the Chrome User Experience Report (CrUX). The critical distinction: Google uses field data (CrUX) for ranking decisions, not lab data. Field data reflects what real users experience on their actual devices and networks. Lab data is valuable for debugging and testing optimizations but cannot measure INP (it uses TBT as a proxy) and may not reflect real-world conditions. Always check field data in PageSpeed Insights or Google Search Console.

Do Core Web Vitals directly affect rankings?

Yes, but as a tiebreaker rather than a dominant ranking factor. Google has described Core Web Vitals as part of the “page experience” signal, which also includes mobile-friendliness, HTTPS, and safe browsing. When two pages are otherwise similar in content quality, relevance, and authority, the page with better Core Web Vitals may rank higher. Studies from 2024 show that improving from “poor” to “good” Core Web Vitals correlates with a 5-7% increase in organic traffic. However, a page with superior content will still outrank a page with perfect Core Web Vitals but thin content.

How can I measure Core Web Vitals for my site?

The best tools for measuring Core Web Vitals in 2026 are: PageSpeed Insights (shows both lab and field data for any URL, includes specific optimization recommendations), Google Search Console (Core Web Vitals report shows site-wide trends with URL grouping), Chrome DevTools Performance panel (detailed traces for debugging specific bottlenecks), web-vitals.js library (add to your site for custom field data collection sent to your analytics), and InstaRank SEO's page speed checker (SEO-focused analysis with scoring across multiple performance dimensions).

Check Your Core Web Vitals Now

Use InstaRank SEO's free page speed checker to analyze your Core Web Vitals, get a detailed performance score, and receive actionable recommendations to improve your LCP, INP, and CLS scores.

Check Page Speed Free Full Website Audit

TL;DR Summary