Core Web Vitals in 2026: What's Changed and What Still Matters

Core Web Vitals have been part of Google's ranking algorithm since mid-2021, but the metrics themselves — and their relative importance — have evolved significantly since then. If your understanding of CWV is still based on what you learned three or four years ago, it is time for an update.

This guide covers where Core Web Vitals stand in 2026, what has changed, what still matters, and the practical steps you should take to ensure your site delivers the experience both users and search engines expect.

A Quick Refresher: What Are Core Web Vitals?

Core Web Vitals are a set of user-centred performance metrics that Google uses to measure how fast, responsive, and visually stable a web page is. They are part of the broader Page Experience signals that influence rankings.

As of 2026, the three Core Web Vitals are:

Largest Contentful Paint (LCP) — measures loading performance. Specifically, it tracks how long it takes for the largest visible content element (typically a hero image or heading block) to render on screen.
Interaction to Next Paint (INP) — measures responsiveness. INP replaced First Input Delay (FID) in March 2024 and tracks the latency of all user interactions throughout a page visit, not just the first one.
Cumulative Layout Shift (CLS) — measures visual stability. It quantifies how much the page layout shifts unexpectedly during loading.

Google considers these "good" when LCP is under 2.5 seconds, INP is under 200 milliseconds, and CLS is below 0.1.

What Changed: FID to INP

The most significant change in the Core Web Vitals lineup was the replacement of First Input Delay with Interaction to Next Paint. This was not a minor tweak — it fundamentally changed how responsiveness is measured.

Why FID Was Insufficient

FID only measured the delay before the browser could begin processing the very first user interaction. It ignored everything that happened after that first click or tap. A page could score perfectly on FID but still feel sluggish if subsequent interactions — scrolling through a menu, toggling filters, clicking a button — were slow to respond.

How INP Is Different

INP measures the responsiveness of every interaction during a user's session and reports the worst one (with some statistical smoothing). This means your site needs to be responsive throughout the entire visit, not just on the first click.

For most sites, passing INP is harder than passing FID was. JavaScript-heavy pages — those with complex client-side rendering, heavy analytics scripts, or bloated third-party widgets — are particularly vulnerable. If your site relies on frameworks that execute significant JavaScript on the main thread, INP is where you will likely see problems.

Addressing these issues often requires a comprehensive technical SEO approach that goes beyond surface-level fixes.

LCP: Still the Most Impactful Metric

Of the three Core Web Vitals, LCP tends to have the most visible impact on both user experience and search performance. A slow LCP means users are staring at a blank or partially loaded page, and the correlation between poor LCP and high bounce rates is well documented.

Common LCP Issues in 2026

Unoptimised images — hero images that are not properly sized, compressed, or served in modern formats (WebP or AVIF) remain the single most common cause of poor LCP scores.
Render-blocking resources — CSS and JavaScript files that prevent the browser from painting content until they are fully downloaded and parsed.
Slow server response times — a Time to First Byte (TTFB) above 800 milliseconds pushes the entire LCP timeline back. This can stem from unoptimised hosting, missing CDN coverage, or heavy server-side processing.
Font loading issues — custom fonts that block text rendering until they are fully loaded. Using font-display: swap and preloading critical font files are standard fixes.

How to Improve LCP

Preload your LCP element. If it is an image, add <link rel="preload"> in the document head. If it is a text block styled with a custom font, preload the font file.
Serve images in next-gen formats. AVIF offers better compression than WebP, which in turn beats JPEG and PNG. Use <picture> elements with format fallbacks.
Defer non-critical JavaScript. Any script that is not needed for the initial render should use defer or async, or be loaded after the LCP element has painted.
Use a CDN. Serve static assets from edge locations close to your users to reduce TTFB.
Optimise server response. If you are on a shared hosting plan that consistently delivers slow TTFB, no amount of front-end optimisation will compensate. Consider upgrading or moving to a platform optimised for performance.

For a deeper dive into speed optimisation, read our guide on site speed and its impact on SEO.

CLS: The Metric That Frustrates Users Most

A poor CLS score might not sound dramatic, but it creates one of the most annoying user experiences on the web. You are about to tap a link, and the page shifts — suddenly you have tapped an ad. You are reading a paragraph, and an image loads above it, pushing the text down. These layout shifts erode trust and drive users away.

Common CLS Causes

Images and videos without explicit dimensions. If the browser does not know the height and width of a media element before it loads, the layout will shift when it renders.
Dynamically injected content. Ads, banners, cookie consent bars, and other elements that appear after the initial render without reserving space.
Web fonts causing a flash of unstyled text (FOUT). When a custom font loads and changes the size of text blocks, the surrounding layout shifts.
Lazy-loaded content above the fold. If you lazy-load images that are visible in the initial viewport, the space is not reserved until the image loads.

How to Fix CLS

Always define width and height attributes on images and videos, or use CSS aspect-ratio to reserve the correct space.
Reserve space for ads and dynamic content using CSS min-height on their container elements.
Use font-display: optional or font-display: swap combined with accurate font size fallbacks to minimise layout shifts from font loading.
Only lazy-load images that are below the fold. The LCP image and any content visible in the initial viewport should load eagerly.

INP: The New Frontier

INP is where most sites still need the most work. Passing the 200-millisecond threshold requires careful attention to how your JavaScript executes and how the browser handles user interactions.

What Causes Poor INP

Long tasks on the main thread. Any JavaScript task that runs for more than 50 milliseconds blocks the browser from responding to user input. Large framework bundles, complex state management, and heavy analytics scripts are common culprits.
Excessive DOM size. Pages with thousands of DOM nodes take longer to update in response to interactions. Every DOM manipulation — adding a class, toggling visibility, updating text — becomes slower as the DOM grows.
Third-party scripts. Tag managers, chat widgets, social media embeds, and advertising scripts often run heavy JavaScript on the main thread. They are outside your direct control but still count towards your INP score.

How to Improve INP

Break up long tasks. Use requestAnimationFrame, setTimeout, or the newer scheduler.yield() API to split heavy JavaScript operations into smaller chunks that do not block the main thread.
Reduce JavaScript bundle size. Audit your dependencies. Remove unused libraries. Use dynamic imports to load code only when it is needed.
Minimise DOM size. Aim for fewer than 1,500 DOM nodes on any given page. Use virtual scrolling for long lists. Remove unnecessary wrapper elements.
Audit third-party scripts. Use Chrome DevTools Performance panel or WebPageTest to identify which third-party scripts contribute most to main thread blocking time. Remove, defer, or replace the worst offenders.
Optimise event handlers. Ensure click, scroll, and input event handlers execute quickly and do not trigger expensive layout recalculations.

How Core Web Vitals Affect Rankings

Google has been transparent that Core Web Vitals are a ranking factor, but they are one signal among many. In competitive niches where content quality and backlink profiles are similar across the top results, page experience can be the deciding factor. In less competitive niches, strong content will still outrank a faster but thinner page.

That said, the indirect effects of poor CWV are arguably more significant than the direct ranking impact:

Bounce rate — slow, unresponsive pages drive users away, sending negative engagement signals.
Conversion rate — every additional second of load time reduces conversions. This has been documented extensively by Google, Amazon, and countless case studies.
Crawl efficiency — faster pages are crawled more efficiently, which matters for larger sites with crawl budget constraints.

Optimising Core Web Vitals is not just about SEO — it is about delivering a better product to your users and converting more of the traffic you already have. This is where conversion rate optimisation and technical SEO intersect.

Tools for Measuring Core Web Vitals

You should measure CWV using both lab data (simulated tests) and field data (real user measurements):

Lab Tools

Lighthouse (built into Chrome DevTools) — simulates a page load and reports CWV scores. Useful for debugging but does not capture real-world variability.
WebPageTest — more configurable than Lighthouse, with options for different devices, connection speeds, and locations.
PageSpeed Insights — combines Lighthouse lab data with Chrome User Experience Report (CrUX) field data.

Field Data

Google Search Console (Core Web Vitals report) — shows how your pages perform for real users, aggregated from Chrome usage data.
CrUX Dashboard — Google's public dataset of real user performance metrics, accessible via BigQuery or the CrUX API.
Web Vitals JavaScript library — Google's open-source library for capturing CWV metrics directly from your users' browsers and sending them to your analytics platform.

Field data always takes precedence. A page might score perfectly in Lighthouse but fail in the field because real users are on slower devices or congested networks.

An Action Plan for 2026

If you are unsure where to start, here is a practical sequence:

Run a CrUX audit. Check your domain-level and page-level CWV data in Search Console. Identify which metric — LCP, INP, or CLS — is your biggest problem.
Fix LCP first. It has the most direct impact on perceived speed and is usually the most straightforward to improve.
Address CLS next. The fixes are typically CSS-level changes that are low-risk and easy to deploy.
Tackle INP last. It often requires deeper JavaScript refactoring and is the hardest to resolve, but it is also the most impactful for sites with significant interactive functionality.
Monitor continuously. CWV is not a one-time project. New deployments, plugin updates, and third-party script changes can regress your scores at any time.

If you would like a professional assessment of your site's technical health and performance, our technical SEO audit covers Core Web Vitals alongside crawlability, indexability, structured data, and every other technical factor that influences your organic visibility.

Get Your Site Up to Speed

Core Web Vitals are not going away. If anything, Google is raising the bar with each iteration — the shift from FID to INP proved that. Investing in performance now protects your rankings and improves every other metric that matters to your business.

Talk to our team about a technical audit that identifies exactly where your site stands and what needs fixing. We will give you a prioritised action plan built around your specific platform, traffic patterns, and business goals.