Core Web Vitals 2026: New Metrics and Strategies

The Core Web Vitals consist of three metrics that collectively quantify the user experience of a website. Largest Contentful Paint (LCP) measures loading speed -- specifically the time until the largest visible element in the viewport is fully rendered. Interaction to Next Paint (INP) measures responsiveness -- the time between a user interaction (click, tap, key press) and the next visual update. Cumulative Layout Shift (CLS) measures visual stability -- how much page elements unexpectedly shift during loading.

Each metric has clearly defined thresholds: LCP is considered good below 2.5 seconds, INP below 200 milliseconds and CLS below 0.1. Values above these boundaries are classified as needs improvement or poor (Source: Google, 2024). Important: these thresholds are based on the 75th percentile of actual user data from the Chrome UX Report (CrUX). This means at least 75% of all page views must reach the good range for the website to pass overall.

The replacement of First Input Delay (FID) with Interaction to Next Paint (INP) in March 2024 was the most significant change to Core Web Vitals since their introduction. FID only measured the delay of the very first interaction on a page -- and completely ignored all subsequent interactions. This meant that websites with a fast first click but slow responses to further actions could still achieve good FID scores. INP closes this gap: the metric evaluates all interactions throughout the entire page visit and reports the slowest (or near-slowest) interaction as the INP value (Source: Google, 2024).

The difference in practice is substantial. According to an analysis by HTTP Archive (2025), after the switch to INP only 65% of all websites achieve good interactivity scores -- compared to over 93% with FID. Particularly affected are websites with extensive JavaScript frameworks, dynamic content and complex event handlers. E-commerce shops, single-page applications and sites with third-party scripts frequently show poor INP values, even though their FID scores were previously in the green zone.

Technically, INP measures three phases of each interaction: the Input Delay (time between user action and event handler start), the Processing Time (execution duration of the event handler) and the Presentation Delay (time until the next frame rendering). All three phases sum up to the INP value. The threshold of 200 milliseconds for 'good' is deliberately ambitious -- it ensures users receive immediate visual feedback on every action. Those who fail to meet this threshold need to fundamentally rethink their frontend optimization.

Largest Contentful Paint remains the central loading speed metric of the Core Web Vitals. LCP measures when the largest visible element in the initial viewport is fully rendered -- typically a hero image, large text block or video poster. The threshold of 2.5 seconds is considered good, between 2.5 and 4 seconds needs improvement and above that is poor (Source: Google, 2024). According to Web Almanac (2025), only 52% of all websites achieve a good LCP score on mobile devices.

LCP optimization requires a systematic approach covering all phases of the loading process. The first step is identifying the LCP element via Chrome DevTools or the performance analyzer. Often the LCP element is a hero image that loads late because it is embedded via CSS background or lazy loading. The solution: embed the LCP image as an element with fetchpriority="high" and loading="eager" and add a hint in the .

Further LCP optimizations include reducing server response time (TTFB below 800 milliseconds), eliminating render-blocking resources through Critical CSS and asynchronous JavaScript loading, optimizing image formats (WebP or AVIF instead of JPEG/PNG) and implementing responsive images with srcset and sizes. Each of these measures directly impacts the LCP value. In our projects we typically achieve LCP improvements of 40-60% through a combination of these techniques (project experience).

Cumulative Layout Shift measures how much visible elements unexpectedly shift during page loading. A CLS value below 0.1 is considered good (Source: Google, 2024). Layout shifts typically arise from images without defined dimensions, late-loading web fonts, dynamically inserted ad banners, cookie consent layers without reserved space and late-loading third-party scripts that insert DOM elements.

CLS optimization starts with a fundamental rule: every visual element needs reserved dimensions before it is fully loaded. For images this means explicit width and height attributes or the CSS property aspect-ratio. For fonts, setting font-display: swap combined with a metrically compatible fallback font with the same space requirements. Google has recommended since 2025 using font-display: optional for non-critical fonts to completely eliminate layout shifts from font swaps (Source: web.dev, 2025).

A frequently overlooked CLS cause is dynamic content above the viewport fold: cookie banners, newsletter popups or late-loading navigation bars that push visible content downward. The solution is either a fixed space reservation (e.g. a placeholder element with the exact height of the banner) or positioning as an overlay (position: fixed) that does not affect document flow. In our technical analysis we identify all CLS causes and prioritize them by impact.

The Core Web Vitals are part of a larger framework: Google's Page Experience Signals. Beyond the three Vitals metrics, additional factors feed into the evaluation: HTTPS as the standard protocol, mobile-friendliness, the absence of intrusive interstitials and a safe browsing experience. Since 2023, Page Experience Signals are no longer reported as a separate ranking factor but flow together with hundreds of other signals into the overall ranking (Source: Google Search Central, 2023).

This does not mean the Vitals have become unimportant -- quite the opposite. Google confirmed in 2025 that Core Web Vitals remain a relevant ranking factor and that websites with good Vitals scores are preferred when content is otherwise equivalent (Source: Google Search Central Blog, 2025). The practical effect is measurable: a study by Searchmetrics (2025) shows that websites in the top 10 search results have on average 28% better LCP scores and 35% better INP scores than websites on positions 11-20.

For your optimization strategy this means: Core Web Vitals alone will not propel poorly ranked pages into the top 10 -- but poor Vitals scores can prevent otherwise strong content from reaching its full ranking potential. The return on investment of a Vitals optimization is particularly high for websites that already have strong content and backlinks but underperform on technical metrics.

A fundamental understanding for Core Web Vitals optimization is the distinction between lab data and field data. Lab data is collected in a controlled test environment -- typically via Lighthouse or Chrome DevTools -- and provides reproducible results under standardized conditions. Field data comes from real users and is aggregated via the Chrome UX Report (CrUX). Google exclusively uses field data for ranking evaluation (Source: Google, 2024).

This distinction has far-reaching consequences. Lab tests typically simulate a mid-tier mobile device with throttled network connection -- the results are often worse than the actual user experience. Conversely, lab tests cannot reliably measure INP because no real user interactions take place. INP values in Lighthouse are synthetic estimates that can deviate significantly from field data. For reliable assessment, CrUX data is therefore indispensable.

The most important measurement tools at a glance: PageSpeed Insights combines lab and field data and shows CrUX status for the entire origin and individual URLs. Google Search Console offers the Core Web Vitals Report with trends over time and groups URLs by status. The Web Vitals Extension for Chrome measures Vitals values in real-time while browsing. And the Chrome DevTools Performance panel enables detailed analysis of individual interactions including all three INP phases. We recommend a combination of all tools in the performance analysis.

Optimizing INP requires a different approach than classic load time optimization. While LCP is primarily improved through network and rendering optimizations, INP depends on JavaScript execution on the main thread. The main thread is the only thread in the browser that can perform DOM updates -- and when it is blocked by long-running JavaScript tasks, it cannot respond to user interactions.

The first strategy is breaking up long tasks. A long task is any JavaScript execution that blocks the main thread for more than 50 milliseconds. Long tasks delay input processing and worsen INP values. The solution: split extensive operations into smaller chunks and give the browser the opportunity to respond to pending interactions between chunks. The scheduler.yield() API (since Chrome 129) enables this interruption elegantly without priority loss.

The second strategy is reducing event handler complexity. Every click or input handler should only perform the minimum work necessary for a visual update. Expensive computations, API calls and DOM manipulations that do not need to be immediately visible are deferred to requestIdleCallback or setTimeout with minimal delay. For compute-intensive operations, Web Workers provide true parallelization outside the main thread.

The third strategy concerns third-party scripts. Analytics tags, ad pixels, chat widgets and social media embeds add substantial work to the main thread and worsen INP values. The solution: consistently load third-party scripts with async or defer, send tracking events via requestIdleCallback and load non-critical scripts only after the initial page interaction (Intersection Observer or user-interaction-based loading). In our technical analysis we systematically identify which third-party scripts have the greatest negative impact on INP.

A typical optimization project shows how the various measures work together. The starting state of a mid-sized online shop: LCP at 4.2 seconds (poor), INP at 380 milliseconds (needs improvement) and CLS at 0.18 (needs improvement). None of the three metrics reached the green zone. After a comprehensive analysis we identified the root causes and prioritized optimization measures by expected impact (project experience).

Three factors were responsible for the LCP value: a slow server (TTFB of 1.8 seconds), a hero image in JPEG format without a preload hint and render-blocking CSS of over 180 KB. Server optimization with opcode cache, database index tuning and CDN integration reduced TTFB to 380 milliseconds. Converting the hero image to WebP with preload and extracting Critical CSS reduced LCP from 4.2 to 1.7 seconds -- a 60% improvement.

The INP value was caused by a jQuery-based mega menu with complex animations, a synchronous API call in the cart button handler and several tracking scripts. Migrating the menu to CSS transitions, making the cart API call asynchronous and moving tracking events to requestIdleCallback reduced INP from 380 to 140 milliseconds. CLS was caused by missing image dimensions, a late-loading cookie banner and dynamically inserted product reviews -- after fixing all three issues, CLS dropped from 0.18 to 0.03.

Core Web Vitals are not a one-time task but require continuous monitoring. New content, plugin updates, design changes and updated third-party scripts can degrade values at any time. A professional monitoring setup includes automatic alerts on regressions, regular reports and historical trend analysis. The Google Search Console provides a basic Core Web Vitals report -- for deeper analysis we recommend additional tools.

Particularly valuable is monitoring at the page level. The overall origin assessment in CrUX may be good while individual template types show poor values. Product detail pages with many images often have worse LCP values than the homepage, category pages with extensive filters have worse INP values, and checkout pages with dynamic forms frequently show elevated CLS values. Granular monitoring uncovers these template-specific issues before they impact overall rankings.

A proven approach is the combination of automated and manual monitoring. Automated lab tests via Lighthouse CI on every deployment catch regressions immediately. Weekly field data checks via Search Console and PageSpeed Insights show actual user experience. And a monthly manual deep-dive with Chrome DevTools Performance tools identifies subtle issues that automated tests miss -- such as INP degradations from new third-party scripts or CLS shifts from dynamically loaded ad banners. This multi-layered approach ensures that performance optimization has lasting impact and is not undone by subsequent changes.

For long-term quality assurance we recommend integrating performance budgets into the development process. A performance budget defines upper limits for JavaScript bundle sizes, CSS files, image sizes and the number of HTTP requests. When a budget is exceeded, the build process fails and prevents the deployment of performance regressions. Tools like Lighthouse CI integrate seamlessly into CI/CD pipelines and automate this check on every deployment. In our projects we set up these budgets as part of the performance strategy.

Google has announced continuous evolution of the Core Web Vitals. Potential future metrics currently being researched include Smoothness (how fluid animations and scrolling feel), Long Animation Frames (LoAF) as a more detailed diagnostic metric for INP issues and improved measurements for soft navigation loading times in single-page applications (Source: web.dev, 2025). While these metrics do not yet factor into ranking evaluation, it is worth monitoring their development.

Another trend is the increasing importance of mobile performance. Google evaluates websites primarily based on the mobile version (Mobile-First Indexing) and Core Web Vitals thresholds are designed for mobile devices. While growing 5G adoption improves network conditions, the computing power of mid-range and budget mobile devices remains limited. INP optimization is therefore particularly relevant for mobile users with weaker hardware.

In summary, the strategy remains clear: websites that invest in all three Core Web Vitals today and establish continuous monitoring are best positioned for future changes to metrics and thresholds. The fundamental principles -- fast loading, responsive interactions and stable layouts -- will always remain relevant regardless of specific metrics. A professional performance optimization pays off not only in rankings but directly in better user experience and higher conversion rates.