What Are Core Web Vitals? Complete 2026 Guide

---

Core Web Vitals are three page experience metrics Google uses to measure whether a webpage delivers a fast, stable, and responsive experience to real users. The three metrics are Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). Google has used them as a ranking signal since June 2021, when the Page Experience update rolled out across all search results.

Understanding Core Web Vitals matters beyond ranking. Multiple industry studies have found correlations between CWV performance and engagement metrics such as bounce rate and conversion rate — though Google has not published a direct causal claim linking CWV scores to these outcomes. Google built them to give developers and SEOs a standardised, measurable proxy for how real users experience page loading — not whether a page loads fast in a controlled lab environment. (web.dev — Core Web Vitals)

This guide covers what each metric measures, how Google applies CWV data in its algorithm, what scores to target, which tools actually matter, how field and lab data differ, and what changed when INP replaced FID in March 2024.

---

Why Google Created Core Web Vitals

Before 2021, Google’s page experience signals were fragmented: mobile-friendliness, HTTPS, absence of intrusive interstitials, and a loosely defined “page speed” signal. None mapped cleanly to what users actually experience during a page load. A site could pass all existing signals while still delivering a frustrating experience — images popping in after content, buttons that take 800ms to respond, text jumping around as fonts loaded.

Google introduced Core Web Vitals to solve that problem with a standardized, user-centric measurement framework. The three metrics are derived from the Chrome User Experience Report (CrUX) — a dataset of real user performance measurements collected from Chrome browsers with usage statistics reporting enabled. This makes CWV field data, not synthetic benchmark data: it reflects actual users on actual devices under actual network conditions worldwide.

The Page Experience update in June 2021 made Core Web Vitals an official ranking signal. Google confirmed from the start that CWV operates as a tiebreaker — a page with strong content and poor CWV will not lose to a page with weak content and perfect CWV. But when content quality and relevance are comparable, CWV is the differentiator. In highly competitive verticals — personal finance, health, e-commerce — many practitioners report CWV as a deciding factor when multiple high-quality pages compete for the same position. Google has not quantified this weighting publicly.

Since 2021, CWV’s influence has extended beyond ranking. The Page Experience signal gating access to Top Stories carousels on mobile now includes CWV. Pages with poor CWV that rank lower due to accumulated page experience disadvantages may appear less frequently in AI Overviews as a consequence — though Google has not published a direct CWV threshold for AI citation eligibility. (Google Search Central — Page Experience)

---

The Three Core Web Vitals: Full Technical Breakdown

LCP — Largest Contentful Paint

What it measures: LCP marks the point in the page load timeline when the largest visible content element in the viewport finishes rendering. (web.dev — LCP) That element is whatever takes up the most screen real estate above the fold — typically a hero image, a large heading, a video poster frame, or a banner.

Thresholds:
| Score | LCP Value |
|——-|———–|
| Good | ≤ 2.5 seconds |
| Needs Improvement | 2.5 – 4.0 seconds |
| Poor | > 4.0 seconds |

Eligible LCP elements: The browser identifies the LCP candidate from: <img> elements, <image> elements inside SVG, <video> poster images, block-level elements with CSS background-image loaded via url(), and block-level text elements containing text nodes. Inline SVG graphics, software-rendered content, and elements hidden with overflow: hidden or opacity: 0 are excluded. The LCP candidate can change during page load — the browser tracks the largest element seen so far and updates it as content renders. The final LCP timestamp is locked in when the user first interacts with the page.

What causes poor LCP:
– Unoptimized hero images — no compression, wrong format (JPEG instead of WebP/AVIF), no <link rel="preload"> hint
– Render-blocking resources in <head> — synchronous JavaScript files that pause HTML parsing before above-the-fold content can render
– Slow server response time (TTFB above 600ms cascades directly into LCP delay)
– Google Fonts without font-display: swap — the browser waits for the font before rendering text, which delays the LCP text element
– Hero images marked with loading="lazy" — lazy loading defers image fetch until the browser determines the element is in the viewport, which defeats the purpose for above-the-fold images
– Hero images defined as CSS background images rather than <img> tags — the browser cannot discover CSS background images until it parses the stylesheet, which typically happens after the initial HTML parse

Fixes ranked by impact:
1. Add <link rel="preload" as="image" href="hero.webp"> in <head> for the LCP image
2. Convert images to WebP or AVIF (30–50% smaller than JPEG at equivalent quality)
3. Move the hero from CSS background-image to an <img> tag with fetchpriority="high"
4. Reduce TTFB by switching to a CDN, enabling server-side caching, and moving to a closer edge location
5. Defer or remove render-blocking JavaScript from <head>
6. Remove loading="lazy" from the hero image

---

INP — Interaction to Next Paint

What it measures: INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. Where FID only captured the delay before the browser began processing the first user interaction, INP measures the full visual response latency — from the moment a user taps, clicks, or presses a key to the moment the browser paints the next visible frame in response. INP captures the complete interaction lifecycle: input delay + processing time + presentation delay. (web.dev — INP)

Google calculates the INP score at the 98th percentile of all interactions during a page session. This means it takes your worst interaction, excluding only the topmost outliers.

Thresholds:
| Score | INP Value |
|——-|———–|
| Good | ≤ 200 milliseconds |
| Needs Improvement | 200 – 500 milliseconds |
| Poor | > 500 milliseconds |

Why INP is harder to pass than FID: FID only measured one number — how many milliseconds before the browser started processing the first user input event. It ignored all JavaScript that ran after that point. A page with heavy post-click JavaScript could score “Good” on FID and “Needs Improvement” on INP because FID never saw the rendering cost. When Google made the switch, roughly 12% of origins with “Good” FID failed to achieve “Good” INP. Sites running heavy JavaScript frameworks, ad networks, and analytics stacks were disproportionately affected.

The three phases of INP:
– Input delay: Time between the user’s input and when the browser starts running the event handler. High input delay usually means the main thread is busy running a long task when the user interacts.
– Processing time: Time the event handler itself takes to execute. This is where heavy JavaScript logic — DOM manipulation, data fetching, component re-renders — shows up.
– Presentation delay: Time between when the event handler finishes and when the browser paints the updated frame. This covers style recalculation, layout, and compositing.

What causes poor INP:
– Long tasks on the main thread — JavaScript running for more than 50ms without yielding causes high input delay for any interactions that occur during those tasks
– Third-party scripts (analytics, chat widgets, consent managers, heatmap tools) that run continuously on the main thread
– Synchronous layout recalculations — JavaScript that reads layout properties (getBoundingClientRect, offsetWidth) immediately after modifying the DOM forces the browser to run layout synchronously
– Heavy component re-renders in React, Vue, or Angular triggered by user events — re-rendering a large component tree blocks the main thread
– Unoptimized event listeners that fire on scroll or resize without debouncing

Fixes:
1. Use scheduler.yield() or setTimeout(fn, 0) inside long tasks to break them into smaller chunks and give the browser a chance to handle user input between chunks
2. Defer all non-critical third-party scripts to defer or load them after DOMContentLoaded
3. Move expensive computation off the main thread using Web Workers
4. Batch DOM reads and writes to avoid forced synchronous layouts
5. Use React’s startTransition or Vue’s nextTick to mark non-urgent updates as lower priority

---

CLS — Cumulative Layout Shift

What it measures: CLS measures visual instability — how much page content shifts unexpectedly as the page loads. (web.dev — CLS) Each layout shift is scored as: impact fraction (proportion of the viewport affected) × distance fraction (how far the shifted element moved as a fraction of the viewport height). CLS is the maximum sum of shift scores within any “session window” — a burst of shifts spanning up to 5 seconds with no gap longer than 1 second between individual shifts.

Thresholds:
| Score | CLS Score |
|——-|———–|
| Good | ≤ 0.1 |
| Needs Improvement | 0.1 – 0.25 |
| Poor | > 0.25 |

What triggers layout shifts:
– Images and <iframe> elements without explicit width and height attributes — the browser reserves no space, so when the element loads it pushes everything below it downward
– Ads inserted dynamically into slots where the slot height was not reserved — the page reflows every time an ad loads
– Web fonts causing FOUT (Flash of Unstyled Text) — the fallback font renders with different character widths than the web font, causing text to reflow when the web font arrives
– Dynamically injected content inserted above existing content — cookie consent banners, newsletter pop-ins, promotional bars that appear at the top of the page
– CSS animations that change layout-affecting properties (top, left, width, height, margin) instead of transform and opacity

What does not count as a layout shift: Shifts triggered by user interaction within 500ms of a click, tap, or keypress are excluded. A navigation menu opening and pushing content down after a user clicks the menu button does not count. Only unexpected, uninitiated shifts count toward CLS.

Fixes:
1. Add explicit width and height attributes to all images and iframes — or use the CSS aspect-ratio property on the container
2. Reserve space for ads with a min-height on the ad slot container before the ad loads
3. Use font-display: optional to prevent FOUT entirely, or font-display: swap with CSS size-adjust to match fallback font metrics
4. Anchor cookie banners and notification bars to the bottom of the viewport using position: fixed; bottom: 0 instead of inserting them at the top
5. Replace layout-animating CSS with transform: translateY() and opacity transitions — these run on the GPU compositor and do not trigger layout

---

Why Google Chose These Three Metrics

Google did not select LCP, INP, and CLS arbitrarily. Each metric was chosen because it is measurable in field data from real users, maps directly to a user-perceptible failure mode, and cannot be gamed by optimising a synthetic lab score.

Why LCP, not TTFB or FCP?

Time to First Byte (TTFB) measures server response speed — but a fast server response tells you nothing about when a page becomes visually useful to users. A page with a 100ms TTFB can still deliver a blank screen for 3 seconds if the rendering is blocked by JavaScript.

First Contentful Paint (FCP) measures when the browser paints the first pixel — but that first pixel may be a loading spinner, a background colour, or a navigation bar. It does not capture whether the page’s primary content has arrived.

LCP captures the moment the largest visible content element renders. That is typically the hero image or main heading — the point at which a user can reasonably determine that the page has loaded. It directly corresponds to a perception threshold that triggers abandonment. (web.dev — LCP)

Why INP, not TBT or FID?

Total Blocking Time (TBT) is a lab-only metric. It measures main-thread blocking during page load, but only in synthetic conditions — it cannot be collected from real users in the field.

First Input Delay (FID) measured the delay before the browser started processing the first user interaction. It ignored all the JavaScript that ran after that point, and it only captured one event per session. A page with heavy post-interaction rendering could score “Good” on FID while delivering a visibly sluggish experience.

INP was designed to address both limitations. It measures the full interaction lifecycle — input delay, processing time, and presentation delay — for every interaction during the session, then reports the 98th percentile. This makes it field-measurable and comprehensive. (web.dev — INP)

Why CLS, not Speed Index or DOM Ready?

Speed Index is a synthetic score computed from a video of the page loading in a lab environment. It is not measurable from real Chrome sessions.

DOM Ready (DOMContentLoaded) is a browser event that fires when HTML is parsed — it does not reflect any user-perceptible state.

CLS captures visual instability that users directly observe: text jumping, buttons moving, images popping into place. A high CLS score correlates with mis-taps, re-reads, and abandonment events — failure modes that a developer timeline event cannot surface. (web.dev — CLS)

---

How Google Applies CWV Scores to Rankings

Google does not run Lighthouse on your site. Rankings are determined by CrUX field data, not lab measurements.

The 75th percentile rule: For each metric, Google takes the 75th percentile of all field measurements for that URL over the trailing 28-day window. If 75% of your users load the page with an LCP ≤ 2.5 seconds, the URL scores “Good” on LCP. The 75th percentile threshold means you must deliver good performance to the majority of users, not just your fastest-loading sessions.

Mobile and desktop are evaluated separately. Google maintains separate CrUX datasets for mobile and desktop sessions. (Chrome UX Report overview) Since Google applies mobile-first indexing to virtually all sites, mobile CrUX data is the primary dataset Google evaluates. A site with excellent desktop CWV and poor mobile CWV will be assessed predominantly on the mobile data — though Google has not published a specific weighting ratio between the two.

The minimum traffic threshold: CrUX requires a minimum number of user sessions before a URL gets its own field data entry. URLs below this threshold fall back to origin-level data — the aggregate CWV performance of all URLs on your domain combined. If your homepage has excellent CWV but a dozen poorly optimized landing pages drag down the origin average, those low-traffic pages inherit the worse origin score.

CWV as a tiebreaker: Google has confirmed repeatedly that CWV does not override content quality. High-quality content with mediocre CWV outranks low-quality content with perfect CWV. But in competitive SERPs where multiple high-quality pages compete for the same position, CWV is the differentiator.

---

Field Data vs Lab Data: What Google Actually Uses

This distinction determines which tools matter for ranking and which tools are for debugging only.

Field data (CrUX) is collected from real Chrome users with usage statistics opted in. It captures the full range of real-world conditions — low-end Android devices, spotty connections, geographic latency, browser extensions. CrUX data is what Google uses for ranking.

Lab data (Lighthouse) runs a controlled synthetic test against a fixed mid-tier mobile device profile with throttled network. It’s reproducible and useful for diagnosing specific issues, but it does not reflect real users and Google does not use it for ranking.

Tools and their data sources:

Diagnostic workflow: GSC → identify page types failing CWV → PageSpeed Insights → confirm the specific metric failing on sample URLs → Chrome DevTools → find the technical root cause → fix → wait 28 days → verify improvement in CrUX.

---

Core Web Vitals Within the Page Experience Signal

CWV is one component of Google’s broader page experience signal. The complete signal includes:

• Core Web Vitals — LCP, INP, CLS
• HTTPS — page served over a secure TLS connection
• No intrusive interstitials — no full-screen popups that block mobile users from accessing content immediately after arrival (with defined exceptions for legally required notices, age verification, and login gates for paywalled content)

Mobile-friendliness is assumed under mobile-first indexing and no longer operates as a separate differentiating signal. Google only indexes mobile-accessible content, so by definition all indexed pages pass the mobile-friendliness check.

Google has not documented a single aggregate Page Experience score. A site can have excellent CWV but still take a page experience hit from an aggressive cookie consent popup that counts as an intrusive interstitial. (Google Search Central — Page Experience)

---

Core Web Vitals and AI Overviews

Google has not published a minimum CWV threshold for AI Overview inclusion. Google’s own documentation on AI Overviews states that source selection prioritises content that is helpful, relevant, and demonstrates expertise — page experience metrics are not listed as direct eligibility criteria. (Google Search Central — AI Overviews)

The indirect relationship: Google draws AI Overview citations primarily from pages that rank well for the relevant query. CWV is one component of the Page Experience signal that influences rankings. Pages with sustained poor CWV that underperform in rankings consequently appear less often in AI Overview citations — not because Google applies a separate CWV filter to AI citations, but because ranking position affects citation frequency.

There is no documented Google statement establishing a direct CWV threshold for AI citation eligibility, independent of ranking.

---

Core Web Vitals by Platform

WordPress: High degree of control over CWV. Caching and optimisation plugins (WP Rocket, LiteSpeed Cache, NitroPack) handle most optimisations at the server and asset level. However, hosting provider quality, CDN configuration, theme architecture, and third-party plugins all affect final scores — control is not absolute. The primary risks are page builders (Elementor, Divi) generating excessive DOM size and third-party plugins injecting scripts on every page load.

Shopify: Partial control. Shopify manages its own CDN and server infrastructure (which performs well), but theme architecture and third-party app scripts are the dominant CWV risk. App scripts often run synchronously on all pages, compounding INP issues for high-app-count stores.

Wix and Squarespace: Platform-managed performance. Users cannot modify JavaScript loading order, critical CSS extraction, or server-side caching behaviour directly. Platform-level CWV scores have improved significantly since 2022 — but the ceiling is set by the platform, not the site owner. Google does not officially classify platforms by CWV control level.

Next.js / React / Vercel: Strong built-in CWV support. Next.js Image component automates WebP conversion, responsive sizing, and LCP preload hints. Server-side rendering eliminates most LCP and CLS issues. The primary INP risk is client-side hydration overhead on initial page load.

Headless and custom builds: Maximum control, maximum responsibility. Teams building custom architectures control every aspect of the rendering pipeline, but must implement all CWV optimizations deliberately rather than relying on platform defaults.

---

Which CWV Should You Fix First?

For most sites, fix in this order: LCP → INP → CLS. LCP has the highest average failure rate across the web, the clearest causal chain from cause to fix, and the most direct impact on perceived load experience. INP failures are concentrated on JavaScript-heavy pages and high-app-count builds. CLS issues are often fast to fix once identified — image dimensions and ad slot sizing account for the majority of CLS failures.

If all three are failing simultaneously, start with LCP — TTFB improvements often cascade positively into both LCP and INP by reducing the volume of work the browser must complete before the page becomes interactive.

---

CWV Prioritisation by Website Type

Different site types have different dominant CWV failure modes. The same fix priority does not apply to all architectures.

These priorities reflect common failure patterns, not universal rules. Always start from your own CrUX data in Google Search Console.

---

CWV Myths vs Reality

---

Common Mistakes When Working with Core Web Vitals

Optimizing for Lighthouse score instead of CrUX. Lighthouse is a diagnostic tool, not a ranking input. A Lighthouse score of 98 does not mean your CrUX field data is “Good.” Always verify improvements in CrUX data before claiming a CWV win.

Fixing desktop and ignoring mobile. Under mobile-first indexing, mobile CrUX scores drive ranking impact. Desktop optimization is secondary.

Applying loading="lazy" to above-the-fold images. This is the most common LCP regression. Lazy loading defers the image fetch until the browser determines the element is in the viewport — for above-the-fold content, that delay adds directly to LCP.

Cookie banners injected at the top of the page. A full-width consent notice that pushes content down causes measurable CLS. Use fixed or sticky positioning anchored to the bottom of the viewport.

Treating CWV as a one-time project. Scores change when content changes, new third-party scripts are added, or traffic patterns shift. A new chat widget, a newly installed analytics tool, or a design refresh can degrade scores overnight. Set up CrUX monitoring in GSC and review weekly.

Chasing a “100” Lighthouse composite score. The Lighthouse score is a weighted composite of multiple diagnostic metrics. Optimizing specifically for the composite score, rather than for the individual CWV metrics Google uses for ranking, leads to misallocated effort.

---

Summary

Core Web Vitals give Google a consistent, user-grounded way to measure page experience quality across the web. The three metrics — LCP for loading, INP for interactivity, and CLS for visual stability — each target a specific failure mode that real users notice and abandon pages over.

For most sites, the priority order is: fix LCP first (it has the highest average failure rate and the clearest improvement path), then address INP (especially on JavaScript-heavy pages), then audit CLS (fast wins from image sizing and banner placement).

Always use CrUX field data from Google Search Console and PageSpeed Insights to measure ranking-relevant scores. Use Lighthouse and Chrome DevTools only to diagnose the root causes. Monitor CrUX on a 28-day cycle after making changes.

The remaining articles in this cluster break down each metric individually — exact rendering pipeline events, platform-specific fixes, and the tooling workflow for each.

---

Next: Core Web Vitals: LCP vs INP vs CLS — What Each Measures and Why Google Chose These Three Metrics

---

Sources

• web.dev — Core Web Vitals: web.dev/articles/vitals
• web.dev — LCP: web.dev/articles/lcp
• web.dev — INP: web.dev/articles/inp
• web.dev — CLS: web.dev/articles/cls
• Google Search Central — Core Web Vitals: developers.google.com/search/docs/appearance/core-web-vitals
• Google Search Central — Page Experience: developers.google.com/search/docs/appearance/page-experience
• Chrome UX Report overview: developer.chrome.com/docs/crux/overview
• Google Search Central — AI Overviews: developers.google.com/search/docs/appearance/ai-overviews