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

A checkout button nobody could click

A fashion retailer in Barcelona spent three months troubleshooting a mystery: mobile conversion rates had dropped 22%, but traffic, pricing, and inventory were all stable. Customer service reported a spike in complaints about the site being “broken on my phone,” yet the development team could not reproduce any bugs. The problem was invisible in functional testing because it was not a bug in the traditional sense. It was a performance problem with three distinct symptoms.

Product pages took 4.7 seconds to display the hero image. Promotional banners loaded after the page content and pushed the “Add to Cart” button downward mid-scroll. Every tap on the size selector froze the browser for nearly 400 milliseconds. In Core Web Vitals terms: LCP of 4.7 seconds (threshold: 2.5), CLS of 0.28 (threshold: 0.1), and INP of 380 ms (threshold: 200). The retailer was failing all three metrics, and the cumulative effect was costing them roughly 2,300 euros per day in lost mobile sales.

This guide breaks down each Core Web Vital metric with current data, explains how to measure them correctly, compares real industry benchmarks, and provides a 90-day roadmap for moving your metrics into the range Google considers “good.” If your website generates revenue, Core Web Vitals are not an optional technical concern — they are a quantifiable business factor.

How to measure your Core Web Vitals: free and paid tools

Before optimizing any metric, you need to know exactly where you stand. And here is a distinction that many teams overlook: lab data and field data measure fundamentally different things, and Google only uses one of those sources for ranking.

Field data vs. lab data

Field data (also called RUM, Real User Monitoring) comes from actual users visiting your site with Chrome. Google collects these metrics through the Chrome User Experience Report (CrUX) and surfaces them in PageSpeed Insights, Search Console, and BigQuery. These data — not lab data — determine whether your site passes Core Web Vitals thresholds for ranking purposes.

Lab data simulates a page load under controlled conditions: an emulated device, a predefined network connection, no extensions, no cache. Lighthouse, WebPageTest, and the Lab mode of PageSpeed Insights all produce lab data. They are indispensable diagnostic tools for identifying root causes, but they do not represent what your real users experience.

Annie Sullivan, an engineer on Chrome’s performance team, has been clear on this point: “Field data and lab data measure different things. A site can pass every Lighthouse audit and still have poor field metrics because its real users are on low-end Android devices on 3G connections.”

Free tools

Google Search Console provides the Core Web Vitals report with field data grouped by status (good, needs improvement, poor) and URL group. It is the mandatory starting point because it shows exactly how Google sees your performance.

PageSpeed Insights combines field data (CrUX) and lab data (Lighthouse) in a single interface. The top section shows field data with the real verdict; the bottom section details improvement opportunities with lab diagnostics.

Chrome DevTools Performance Panel lets you record interactions in real time and analyze each metric down to individual trace events. It is the most powerful tool for diagnosing INP issues.

Web Vitals Extension for Chrome displays metrics in real time as you browse any site, overlaid in the corner of the screen.

Paid tools

Calibre, SpeedCurve, and DebugBear offer continuous monitoring with alerts, historical trends, and segmentation by device, country, and page type. For sites with thousands of URLs, these tools surface patterns that point-in-time tools cannot detect.

CrUX Dashboard (free, built on Google Data Studio and BigQuery) lets you create custom dashboards with historical field data segmented by origin and connection type. It is the most powerful free option, though it requires basic SQL knowledge.

HTTPArchive publishes global Core Web Vitals data that lets you contextualize your metrics against overall web performance. According to their 2025 report, only 42% of websites simultaneously pass all three Core Web Vitals thresholds.

What are Core Web Vitals and why Google uses them as a ranking factor

Core Web Vitals are a set of three metrics that quantify specific aspects of user experience on a web page: visual loading speed, layout stability during load, and responsiveness to user interactions. Google introduced them in May 2020 and made them a ranking signal in June 2021 as part of the page experience update.

Google’s official documentation on web.dev states the purpose clearly: “Web Vitals is an initiative by Google to provide unified guidance for quality signals that are essential to delivering a great user experience on the web.” These are not arbitrary metrics but indicators selected because they correlate directly with user behavior: bounce rates, conversion rates, and satisfaction scores.

In 2026, the three Core Web Vitals are:

• LCP (Largest Contentful Paint): measures perceived loading speed. Good threshold: under 2.5 seconds.
• CLS (Cumulative Layout Shift): measures visual stability. Good threshold: under 0.1.
• INP (Interaction to Next Paint): measures responsiveness. Good threshold: under 200 ms.

These three metrics do not operate in isolation. Google evaluates page experience as a set of signals that includes Core Web Vitals alongside HTTPS, absence of intrusive interstitials, and mobile-friendliness. But Core Web Vitals are the only part of that equation that requires continuous measurement with real field data.

The question that marketing and product teams need to answer is not “do Core Web Vitals matter?” but “how much revenue are we leaving on the table by not optimizing them?” Rakuten’s data answers that question: 33% more conversions and 53% more revenue per visitor. Those numbers are not outliers. They are representative of what happens when a site moves from “poor” to “good” across all three metrics.

For a broader view of how Core Web Vitals fit within overall technical strategy, see our guide on web speed and SEO.

INP (Interaction to Next Paint): the metric that replaced FID

In March 2024, Google replaced FID (First Input Delay) with INP (Interaction to Next Paint) as the official responsiveness metric within Core Web Vitals. This was not a cosmetic change: it represented a fundamental shift in how Google evaluates page interactivity.

Why Google retired FID

FID only measured the delay of the user’s first interaction with the page. If the user clicked a button during initial load and the browser took 300 ms to respond, FID recorded 300 ms. But if every subsequent interaction — scrolling, clicking menus, submitting forms — was also slow, FID did not capture that. A site could have an excellent FID score and a terrible interactivity experience.

INP fixes that limitation. It measures the latency of every user interaction throughout the entire visit and reports the 98th percentile (technically, the worst interaction excluding extreme outliers). This means INP reflects the complete interactivity experience, not just first contact.

Thresholds and diagnosis

• Good: INP under 200 ms
• Needs improvement: INP between 200 and 500 ms
• Poor: INP above 500 ms

According to HTTPArchive data, INP is the metric where the most sites fail. While approximately 80% of sites pass the LCP threshold and 75% pass CLS, only 65% meet the INP threshold. The reason is structural: for years, development teams prioritized initial load speed (optimizing LCP) and visual stability (preventing CLS) without paying attention to the latency of post-load interactions.

The most frequent causes of poor INP are: JavaScript event handlers that execute too much code on the main thread, DOM reflows triggered by style mutations inside event handlers, and third-party scripts (analytics, A/B testing, chat widgets) that compete for the main thread during user interactions.

How to debug INP

Chrome DevTools Performance Panel is the most effective tool. Record an interaction session and examine the Long Animation Frame (LoAF) API to identify which scripts block the main thread during each interaction. Look for tasks exceeding 50 ms and decompose each one to locate the responsible code.

An effective technique is yielding: breaking long JavaScript tasks into smaller chunks using scheduler.yield() or setTimeout to return control to the browser between fragments. This allows the browser to process visual updates without waiting for the entire computation to finish.

LCP (Largest Contentful Paint): what it measures and 2026 thresholds

LCP measures the time it takes to render the largest visible content element in the viewport. That element can be an image, a text block, a video, or an SVG element. It is the metric that best captures the user’s perception of “how long the page takes to load,” because it reflects the moment when the main content becomes visible.

Thresholds

• Good: LCP under 2.5 seconds
• Needs improvement: LCP between 2.5 and 4 seconds
• Poor: LCP above 4 seconds

Google measures LCP at the 75th percentile of field data: if 75% of a URL’s page loads have an LCP below 2.5 seconds, that URL passes the threshold.

The four phases of LCP

According to web.dev documentation, LCP time breaks down into four sub-phases that guide diagnosis:

1. Time to First Byte (TTFB): time from the HTTP request to the first response byte. Depends on the server, CDN, and redirects.
2. Resource Load Delay: time between TTFB and the start of downloading the LCP resource. If the LCP image is not in the initial HTML (but discovered after parsing CSS or executing JavaScript), this delay grows.
3. Resource Load Duration: download time of the LCP resource. Depends on file size and bandwidth.
4. Element Render Delay: time between the resource finishing download and its rendering on screen. Render-blocking CSS and DOM-modifying JavaScript can extend this phase.

Common causes and solutions

The most common cause of slow LCP is large, unoptimized hero images. A 2 MB JPEG that could be a 200 KB WebP adds unnecessary seconds to LCP. Direct solutions: use modern formats (WebP, AVIF), implement responsive images with srcset, preload the LCP image with <link rel="preload">, and never lazy-load the above-the-fold image.

The second most frequent cause is render-blocking CSS. If your page loads 300 KB of CSS before rendering any content, LCP is delayed proportionally. The solution is to inline critical CSS (what is needed to render above-the-fold content) and defer the rest using media="print" or asynchronous loading.

Web.dev data confirms that TTFB is frequently the largest component of LCP on sites with slow servers: “If your TTFB is slow, it’s hard to meet the targets for the rest of the metrics.” Using a CDN with edge caching and optimizing server database queries are the two most effective steps for reducing TTFB.

Benchmarks by industry: what scores the market leaders achieve

Knowing that the LCP threshold is 2.5 seconds is necessary but not sufficient. Businesses need competitive context: what scores do sites in their industry actually achieve? HTTPArchive and CrUX data answer this question with real figures.

E-commerce

E-commerce is the sector where Core Web Vitals have the most direct and documented business impact. 2025 data shows that e-commerce sites passing all three thresholds have a 24% higher conversion rate than those that do not.

Sector leaders (Amazon, Zalando, ASOS) maintain a median LCP below 1.8 seconds, CLS below 0.04, and INP below 150 ms. These sites invest in dedicated performance teams with real-time monitoring and performance budgets that block deployments when any metric exceeds a defined threshold.

For mid-sized e-commerce sites, the realistic benchmark is: LCP under 2.2 seconds, CLS under 0.08, and INP under 180 ms. Reaching these figures requires product image optimization, third-party script management, and server-side rendering or pre-rendering for category pages.

Media and publishing

Content sites face a particular CLS challenge: dynamic ads that load after editorial content shift page elements, generating CLS scores that frequently exceed 0.2. The best-performing publishers (The Guardian, Financial Times) have implemented ad slots with reserved dimensions and controlled lazy loading to minimize layout shifts.

For LCP, content sites typically have an advantage because their primary elements are text, not heavy images. The leader benchmark is LCP under 1.5 seconds for text articles.

SaaS and B2B

SaaS sites generally have good Core Web Vitals on marketing pages (static landing pages) but poor scores in their web applications. Since Google evaluates pages that users find through search, landing pages are what matters for ranking. The sector benchmark is LCP under 2.0 seconds and CLS under 0.05.

The Rakuten case study, documented by web.dev, is the most cited reference in the technology sector: 33% more conversions and 53% more revenue per visitor after optimizing Core Web Vitals. Annie Sullivan from the Chrome team commented on this case: “It is a perfect example of how user-centric metrics translate directly into business outcomes.”

Professional services and corporate sites

This sector has the greatest variability. Corporate sites running enterprise CMS platforms (Adobe Experience Manager, Sitecore) frequently have LCP above 3 seconds due to the complexity of the technology stack. The best performers are those that have adopted static generation architectures (Astro, Next.js) with edge CDNs: LCP under 1.2 seconds is achievable for institutional sites with low content dynamism.

CLS (Cumulative Layout Shift): what it measures and common causes

CLS measures the sum of all unexpected layout shifts of visible elements during the page’s lifespan. Every time a DOM element changes position without user interaction — for example, an image loading and pushing text downward, or a banner appearing from above — it generates a layout shift that contributes to the CLS score.

Thresholds

• Good: CLS under 0.1
• Needs improvement: CLS between 0.1 and 0.25
• Poor: CLS above 0.25

How it is calculated

CLS is not a simple sum of all shifts. Google uses a “session windows” system that groups shifts occurring in rapid bursts (less than 1 second apart, with a maximum of 5 seconds per window). The final CLS score is the maximum score across all session windows. This calculation, updated in 2021, corrects a limitation of the original method that unfairly penalized pages where users spent a long time (web applications, infinite feeds).

Each individual shift is calculated as: impact fraction (percentage of viewport affected) multiplied by distance fraction (shift distance as a percentage of viewport). An image occupying 50% of the viewport that shifts 20% generates a shift score of 0.1.

The five most frequent causes of high CLS

1. Images and videos without declared dimensions. If an image has no width and height attributes in the HTML, the browser cannot reserve space before downloading it. When the image loads, it pushes all content below it downward. The fix is to always declare dimensions or use the aspect-ratio CSS property.

2. Dynamic ads and embeds. Ad slots managed by Google AdSense, ad managers, or programmatic networks frequently change size after initial load. Reserving the slot space with a fixed-height container or using the min-height property reduces the impact.

3. Web fonts causing FOUT/FOIT. When a web font loads after text has been rendered, the browser may switch from the fallback font to the web font, causing a visible shift. Using font-display: swap combined with size-adjust on the fallback font minimizes the size change.

4. Dynamically injected content. Cookie banners, notification bars, chat widgets, and UI elements inserted into the DOM after initial load can displace existing content. The solution is to reserve space or use fixed/sticky positioning for these elements.

5. Lazy-loaded images above the fold. If lazy loading is applied to images within the initial viewport, the browser first renders the page without them and then inserts them, causing a shift. Above-the-fold images should never have loading="lazy".

CLS improvement is one of the optimizations with the highest immediate return. According to data cited in the web.dev case study, reducing CLS from 0.25 to 0.05 can increase conversions by 15% because users stop accidentally clicking on elements that were not their intended target.

A 90-day roadmap for improving your Core Web Vitals

Improving Core Web Vitals is not a one-day project. It requires a sequential approach that prioritizes metrics based on business impact and resolution complexity. This roadmap is designed for teams with limited resources that need measurable results within a quarter.

Phase 1: Diagnosis and quick wins (Weeks 1-2)

Goal: establish baselines and resolve problems that do not require architectural changes.

1. Run PageSpeed Insights on the 20 URLs with the most organic traffic. Document field LCP, CLS, and INP for each.
2. Cross-reference with Google Search Console > Core Web Vitals to identify URL groups with common patterns.
3. Implement immediate image optimizations: convert to WebP/AVIF, add explicit dimensions in HTML, preload the LCP image, remove lazy loading from above-the-fold content.
4. Add font-display: swap and size-adjust to all web fonts.
5. Reserve space for ad slots and embeds with min-height.

Expected result: LCP improvement of 20-30% and CLS improvement of 40-60% from these changes alone.

Phase 2: LCP and CLS optimization (Weeks 3-6)

Goal: bring LCP and CLS into the “good” range for 90% of URLs.

1. Audit render-blocking CSS: inline critical CSS and defer the rest. Tools like Critical (by Addy Osmani) automate the extraction.
2. Implement a CDN if you do not have one. An edge CDN reduces TTFB by 40% to 70% depending on geographic distance to the origin server.
3. Optimize the LCP resource discovery chain: ensure the LCP image or resource is referenced directly in the HTML, not discovered after parsing CSS or executing JavaScript.
4. Review all third-party scripts: analytics, A/B testing, chat widgets, social media pixels. Defer non-critical ones with async or defer. Consider loading non-essential ones only after user interaction.
5. Implement performance budgets: define maximum size thresholds for JavaScript (under 200 KB compressed), CSS (under 50 KB critical), and images per page.

Phase 3: INP optimization (Weeks 7-10)

Goal: bring INP into the “good” range by identifying and resolving slow interactions.

1. Use Chrome DevTools with the Long Animation Frames (LoAF) API to identify interactions exceeding 200 ms.
2. Implement code splitting for JavaScript: load only the code needed for each page and defer the rest.
3. Apply yielding in long event handlers: break tasks exceeding 50 ms into smaller chunks using scheduler.yield().
4. Move heavy computations off the main thread using Web Workers where possible.
5. Audit third-party scripts that block the main thread during interactions. A/B testing tools and tag managers are the most frequent offenders.

Phase 4: Monitoring and maintenance (Weeks 11-12)

Goal: establish an alert system to prevent regressions.

1. Set up automated alerts (DebugBear, SpeedCurve, or CrUX Dashboard) to detect regressions in any of the three metrics.
2. Integrate Lighthouse CI into your deployment pipeline to block releases that worsen Core Web Vitals.
3. Schedule a monthly review of the Core Web Vitals report in Search Console to detect trends.
4. Document performance decisions in a performance budget that the development team consults before adding new scripts or features.

For a platform-specific implementation, see our guide on Core Web Vitals for e-commerce. If your site runs on WordPress, the Core Web Vitals for WordPress guide covers that ecosystem’s specifics. And if you need professional support, our Core Web Vitals optimization service includes a full audit, implementation, and ongoing monitoring.

Conclusion: Core Web Vitals as a shared language for business and tech

Core Web Vitals solved a problem that the SEO industry had carried for over a decade: the lack of objective, standardized, and publicly available metrics for measuring user experience on the web. Before 2020, every tool measured “speed” differently, marketing and development teams spoke different languages, and executives had no way to know whether their site was fast or slow without relying on subjective opinions.

In 2026, LCP, CLS, and INP are the de facto standard. Google uses them for ranking. Development teams use them to set performance budgets. Executives use them to justify infrastructure investments. And the data consistently shows that improving them has a direct impact on conversions, revenue, and user satisfaction.

The most frequent mistake is treating Core Web Vitals as a one-time project: “we passed the audit, it’s done.” The reality is that every new third-party script, every design change, every content update can introduce a regression. The companies that maintain their metrics in the “good” range over time are those that have integrated performance monitoring into their daily workflow, not those that run a massive optimization once a year.

The data is clear. The tools are available. The thresholds are public and stable. The only variable is whether your team prioritizes user experience as a business factor or relegates it to a secondary technical task. Core Web Vitals make that decision measurable.