Core Web Vitals 2026: Which Metrics Actually Matter
The updated Core Web Vitals set for 2026 (LCP, INP, CLS) — what they measure, what the thresholds are, how to improve them, and why page speed matters more in 2026 than it did in 2020.
Core Web Vitals are a set of website performance metrics that Google has used as a ranking factor since 2021. By 2026, the metrics have changed several times: FID is gone, INP has arrived, and thresholds have tightened. Once again it has been proven: page load speed is not just a UX metric — it is a direct business factor.
This article covers the current Core Web Vitals set for 2026, the up-to-date thresholds, and practical steps for improving each metric.
The Current Core Web Vitals
Since March 2024, Google officially replaced FID (First Input Delay) with INP (Interaction to Next Paint). The modern set:
| Metric | What It Measures | Good | Needs Improvement | Poor |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Time until the largest visible element is rendered | < 2.5 s | 2.5–4.0 s | > 4.0 s |
| INP (Interaction to Next Paint) | Page response time to a user action | < 200 ms | 200–500 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | Shift of page elements during loading | < 0.1 | 0.1–0.25 | > 0.25 |
A site is considered to have "passed Core Web Vitals" when all three metrics at the 75th percentile of visits fall in the green zone. That means for 75% of visitors, all three scores must be "good." This is not the same as the average — it is not even the median. It is a requirement covering the majority of users, including those on slow devices.
Impact on Rankings
The direct impact of Core Web Vitals on Google positions is moderate — it is one of roughly 200 ranking factors, and not among the most heavily weighted. But the indirect impact is enormous:
- Pogosticking: a user opens a slow site, gives up waiting for it to load, returns to the search results, and clicks on a competitor. The search engine sees this and drops the site's positions.
- Bounce rate: a high bounce rate caused by slow loading → a signal that "the content doesn't engage" → a ranking drop.
- Mobile-first indexing: the difference between a fast and a slow site is far more noticeable on mobile devices, and Google indexes the mobile version.
In Yandex, the impact works through the same behavioral signals. Page speed is not singled out as a standalone factor, but through user behavior it is one of the most powerful indirect levers.
The financial side: Google research shows that slowing LCP from 1 to 3 seconds increases the bounce rate by approximately 32%. For e-commerce, that means direct revenue losses; for lead generation, it means lost enquiries.
LCP: How to Improve It
LCP measures the time from when the page starts loading until the largest visible element is rendered — typically the main header image, a hero block, or a headline.
Top causes of slow LCP:
Large, Unoptimised Images
The most common cause in 2026. A hero image weighing 2 MB adds roughly +1.5 seconds to LCP on mobile.
Solution:
- Convert to WebP or AVIF (saving 30–60% compared to JPEG/PNG)
- Correct
srcsetfor responsive images fetchpriority="high"on the main hero image (an attribute supported since 2023)preloadcritical resources in<head>
Render-Blocking Resources
CSS and JS loaded in <head> without async/defer block page rendering until they are fully loaded.
Solution:
- Inline critical CSS (for the above-the-fold block) directly in HTML
- Load remaining CSS asynchronously via
<link rel="preload" as="style"> - JS — use
deferorasyncwhere it is safe to do so
Slow Server
If TTFB (Time to First Byte) exceeds 600 ms, no amount of client-side optimisation will push LCP into the green zone.
Solution:
- CDN for static assets
- Edge caching for HTML (where the content allows it)
- Server-side rendering → static export where possible (Next.js, Astro)
- Backend query and database optimisation
Third-Party Script Slowdowns
Analytics tools, live chats, and ad networks all slow pages down.
Solution:
- Audit third-party scripts — identify what is actually needed and what can be disabled
- Load scripts with
<script async>or<script defer> - Load non-critical scripts via
requestIdleCallback
INP: The New Metric Replacing FID
INP replaced FID in March 2024, and this was not a cosmetic change. FID measured only the first interaction (the very first click); INP measures all interactions throughout a session. This makes it a significantly stricter metric.
What counts as an "interaction":
- A mouse click or a tap on a touch device
- A keyboard keypress
- Any JS event that requires a UI response
INP measures the time from the interaction to the next painted frame — in other words, how quickly the interface responds.
Top causes of poor INP:
Heavy JavaScript Tasks
If an onClick handler blocks the main thread for 300+ ms, INP lands in the red zone. In 2026, this is a common problem with heavy React applications.
Solution:
- Break long tasks into chunks using
requestIdleCallback - Use server components / RSC to reduce the volume of client-side JS
- Web Workers for heavy computations
- Profile in Chrome DevTools → Performance, look for Long Tasks
JS Bundle Size
Every additional megabyte of JS means extra time for parsing, compilation, and execution. By 2026, a typical React site can easily reach 2–4 MB of JS — and that is far too much.
Solution:
- Code splitting by route (Next.js does this automatically)
- Tree shaking — removing unused code
- Lazy loading of heavy components
- Dependency audit: "do we really need all of lodash?"
Forced Layouts / Reflows
JS that modifies the DOM and immediately reads geometry forces the browser to recalculate the entire layout synchronously.
Solution:
- Group reads and writes (read all dimensions first, then write)
- CSS
contain: layout stylefor isolated components - Use
transformandopacityfor animations instead of top/left/width/height
CLS: Visual Stability
CLS shows how much page elements "jump" during loading. A high CLS means users click the wrong buttons, read shifting text, and get frustrated.
Top causes of high CLS:
Images Without Dimensions
If an image in HTML lacks width and height attributes, the browser does not know its size before loading and reserves zero space. Once the image loads, everything below it shifts.
Solution:
- ALWAYS specify
widthandheightfor all images - For responsive images — use aspect-ratio CSS
- In Next.js — use the
<Image>component and always provide explicit dimensions
Late-Loading Fonts
Loading a custom font causes text to be displayed in the system font first, then re-rendered in the custom font at a different width. Each such re-render is a potential CLS event.
Solution:
font-display: optionalorfont-display: swapwith a FOUC fallback- Use
size-adjust,ascent-override, anddescent-overridein@font-faceto match the fallback font's metrics to the custom font - Host fonts on your own server (not Google Fonts) for predictable load speed
Ads, Chat Widgets, and Banners
Late-loading external blocks pop in and push content around.
Solution:
- Reserve a
min-heightfor the ad container in advance - Avoid loading above-the-fold banners due to their CLS contribution
A Real-World Site Story
A typical scenario: an online store on a ready-made platform. Before optimisation:
- LCP: 4.8 s (mobile)
- INP: 380 ms
- CLS: 0.18
After three weeks of work (hero image compression, lazy-loading images, code splitting, fixed sizes on everything):
- LCP: 1.9 s
- INP: 145 ms
- CLS: 0.04
Effect on business metrics:
- Bounce rate dropped by 23%
- Pages per session increased by 31%
- Add-to-cart conversion rate rose by 18%
- Yandex rankings improved across 60% of the semantic core
And all of this — without a single new page or backlink. Just code and media optimisation.
2026 Audit Checklist
- Open PageSpeed Insights on key pages (homepage, services, articles, cart). Record LCP, INP, and CLS on mobile.
- If LCP > 2.5 s — audit images and render-blocking resources.
- If INP > 200 ms — Chrome DevTools Performance → look for Long Tasks, audit third-party scripts.
- If CLS > 0.1 — audit image dimensions, fonts, and dynamically injected blocks.
- Regular monitoring in Google Search Console → Core Web Vitals (for the index, over a 28-day window).
- Real User Monitoring (RUM) — set up a tool such as Yandex Metrika Webvisor with performance metric recording, or build a custom collector. Lab metrics (PageSpeed) often differ from field data by 30–50%.
Summary
Core Web Vitals in 2026 are not a "technical whim from Google" — they are a real factor in user retention and search rankings. Sites with green metrics are not only perceived better by users, they also gain an advantage in search results — especially on mobile.
If you are unsure about your site's current scores, or you know there are problems but are not sure where to dig, reach out to us. A free express performance audit in 2 business days.