Core Web Vitals 2026: guide for businesses - Ighenatt Blog

Google has been using Core Web Vitals as a ranking signal since 2021. What started as a bet on user experience has become a standard that separates the sites Google rewards from those it silently penalises. With the consolidation of INP as the official metric in 2024, the landscape is clearer than ever.

This guide breaks down what each metric measures, what thresholds Google requires, how to measure them correctly and what concrete actions will improve your scores in the next 90 days.

What are Core Web Vitals and why do they matter

Core Web Vitals are three metrics that quantify the real experience of users when interacting with a web page. Google selected them because they represent the three most critical aspects of the loading experience:

• LCP (Largest Contentful Paint): How quickly the main content appears.
• CLS (Cumulative Layout Shift): Visual stability during loading.
• INP (Interaction to Next Paint): How quickly the page responds to user interactions.

Google integrated them into its algorithm within the Page Experience signal because they correlate directly with business metrics. Sites that meet all three thresholds tend to receive significantly more organic clicks: users stay longer, bounce less and generate stronger engagement signals.

Google’s logic is transparent: if two pages compete for the same keyword with equivalent content and authority, the one that offers a better technical experience wins the position. It is a tiebreaker factor, but in competitive markets, tiebreakers decide the first page.

LCP (Largest Contentful Paint): Measures and Thresholds in 2026

LCP measures the time it takes to render the largest visible element within the viewport. It can be a hero image, a large block of text or a video. Google sets three ranges:

• Good: Less than 2.5 seconds
• Needs improvement: Between 2.5 and 4.0 seconds
• Poor: More than 4.0 seconds

Frequent causes of a slow LCP

LCP typically degrades for four main reasons: slow server response times (high TTFB), hero images that are not optimised or served without modern formats (WebP, AVIF), CSS and JavaScript that block rendering, and client-side rendering that delays the appearance of the main content.

The guide on the causes of slow LCP and how to resolve them analyses each cause with its corresponding technical solution.

High-impact optimisations for LCP

The three actions that have the most impact on LCP are: implementing preload (<link rel="preload">) for the LCP image or resource of each page, serving images in next-generation formats with explicit dimensions, and reducing TTFB with CDN-level cache and Brotli compression.

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

CLS quantifies the unexpected position changes of visible elements during the lifespan of the page. A high CLS means that content “jumps” while the user is trying to read or interact, generating frustration and click errors.

• Good: Less than 0.1
• Needs improvement: Between 0.1 and 0.25
• Poor: More than 0.25

The five usual culprits of CLS

1. Images and videos without declared dimensions: The browser does not reserve space until the resource is downloaded, causing a reflow when it renders.
2. Dynamic ads and embeds: Advertising slots that load late push existing content downward.
3. Web fonts without font-display: If the font loads after the text, the size change between the fallback font and the final one generates a layout shift.
4. Dynamically injected content: Cookie banners, notification bars and elements inserted by JavaScript without reserved space.
5. Animations that modify layout properties: Using top, left, width or height in animations instead of transform and opacity.

The most effective solution is to always declare the dimensions of multimedia elements (width and height in HTML), use aspect-ratio in CSS for responsive containers, and reserve fixed space for ads and embeds with min-height.

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

In March 2024, Google replaced FID (First Input Delay) with INP as the official interactivity metric. The change was significant: FID only measured the latency of the first user input, while INP measures the latency of all interactions throughout the entire session and reports the 75th percentile of the worst ones.

• Good: Less than 200 milliseconds
• Needs improvement: Between 200 and 500 milliseconds
• Poor: More than 500 milliseconds

Why INP is more demanding than FID

FID was relatively easy to pass because it only considered the first interaction, which usually occurs when the page has already finished loading its JavaScript. INP exposes problems that FID hid: slow dropdown menus, forms that block the main thread when validating, and carousels that stutter when swiping.

How to improve INP

The most effective strategies are: breaking up long JavaScript tasks into smaller ones using requestIdleCallback or scheduler.yield(), moving heavy work to Web Workers, reducing the total size of JavaScript by removing unnecessary dependencies, and using content-visibility: auto to limit rendering work outside the viewport.

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

There are two types of measurement, and it is essential to understand the difference:

Field Data

Comes from real users browsing with Chrome and is aggregated in the Chrome UX Report (CrUX). This is the data Google uses to evaluate rankings. Tools that display it:

• PageSpeed Insights: Shows CrUX data when available, alongside Lighthouse diagnostics.
• Google Search Console: The Core Web Vitals report groups URLs by status (good/needs improvement/poor).
• CrUX Dashboard (Looker Studio): Allows analysis of the historical evolution of metrics by origin or URL.

Lab Data

Generated in controlled environments and useful for diagnosing specific problems, but does not reflect the real experience or directly impact rankings:

• Lighthouse (Chrome DevTools): Full audit with technical recommendations.
• WebPageTest: Allows configuration of location, device and connection to simulate real scenarios.
• Chrome DevTools Performance Panel: Granular analysis of JavaScript, rendering and network.

The golden rule: use lab data for diagnosis, but evaluate the impact on rankings with field data.

Benchmarks by sector: what scores the leaders achieve

Data from the HTTP Archive Web Almanac 2024 show notable differences between sectors. Knowing them helps to set realistic targets:

Ecommerce: Only 57% of sites meet all three thresholds on mobile. LCP is the most problematic metric due to heavy product images and third-party scripts (analytics, remarketing, chat). Sector leaders achieve LCP < 1.8s through aggressive image optimisation and lazy loading.

Media and news: CLS is the main problem due to dynamic ads. Sites that reserve fixed space for advertising slots achieve CLS < 0.05. LCP is usually good because the main content is text.

SaaS and technology: Generally the best positioned, with 78% meeting all three thresholds. Modern architecture (frameworks such as Astro, Next.js with SSR) and less dependence on third-party scripts facilitate good scores.

Professional services: The sector with the best metrics proportionally, as corporate sites tend to have few external dependencies and static content. The risk lies in overloaded WordPress themes with plugins.

The relationship between web speed and SEO is direct: every tenth of a second counts when the competition is at the same thresholds.

Roadmap to improve your Core Web Vitals in 90 days

Weeks 1-2: Diagnosis

Run PageSpeed Insights on the 20 pages with the most traffic. Record the LCP, CLS and INP values on both mobile and desktop. Review the Core Web Vitals report in Search Console to identify URLs grouped as “poor”. Prioritise: pages with the most traffic and worst metrics come first.

Weeks 3-4: LCP (fastest impact)

Implement preload for the LCP resources of each page. Convert hero images to WebP/AVIF with explicit dimensions. Enable Brotli compression on the server. If TTFB exceeds 600ms, evaluate CDN or server-level cache. These actions typically reduce LCP by between 0.5 and 2 seconds.

Weeks 5-6: CLS (preventive corrections)

Declare width and height on all images and videos. Reserve space for ads with min-height. Implement font-display: swap or optional on web fonts. Use aspect-ratio for embedded video containers. CLS responds quickly because the changes are preventive, not performance optimisations.

Weeks 7-8: INP (the most technical metric)

Identify long tasks with the Chrome DevTools Performance Panel. Break up scripts that block the main thread for more than 50ms. Evaluate whether you can defer or remove non-critical third-party scripts. Implement content-visibility: auto in below-the-fold sections.

Weeks 9-12: Monitoring and adjustment

Field data in CrUX is aggregated in 28-day windows. Wait at least 4 weeks after implementations to see changes reflected. Set up alerts in Search Console and review monthly evolution. Document each change and its impact to justify future investments.

If your team needs help with technical implementation, our Core Web Vitals optimisation service includes diagnosis, implementation and continuous monitoring.

Frequently asked questions about Core Web Vitals

Core Web Vitals are no longer a novelty: they are a consolidated standard that Google uses to decide which sites deserve the first page. Run PageSpeed Insights on your ten highest-traffic pages right now. If any return an LCP above 2.5 seconds or a CLS above 0.1, you have a specific problem to solve. Tell us what you found and we will tell you where to start.