Core Web Vitals in 2026: Thresholds and What Moved
The metrics did not change this year. Plenty of the tooling around them did. Here is what is actually true right now.
Three metrics, and the same three since 2024. Largest Contentful Paint should land at 2.5 seconds or less, Interaction to Next Paint at 200 milliseconds or less, and Cumulative Layout Shift at 0.1 or less. Each is judged at the 75th percentile of real page loads, split between mobile and desktop.
What are the Core Web Vitals thresholds in 2026?
These come straight from the metric pages on web.dev, which is where Google publishes the definitions. Everything is scored at the 75th percentile of page loads, so you pass when three quarters of your real visitors get a good result, not when your laptop does.
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP | Loading, when the biggest visible thing finishes rendering | 2.5 seconds or less | 2.5 to 4.0 seconds | Over 4.0 seconds |
| INP | Responsiveness across every interaction on the page | 200 ms or less | Over 200 ms up to 500 ms | Over 500 ms |
| CLS | Visual stability, the worst burst of unexpected shifting | 0.1 or less | Over 0.1 up to 0.25 | Over 0.25 |
Did Core Web Vitals actually change in 2026?
No. Not the metric set, not a single threshold. The last structural change was on 12 March 2024, when Interaction to Next Paint became a stable Core Web Vital and First Input Delay was retired, which web.dev announced in its INP becomes a Core Web Vital post. Since then the set has been three stable metrics with no experimental or pending replacement named. Google's own rule is that stable Core Web Vitals will not change more than once per year, and 2025 and 2026 both went by without one.
What did move is the measurement layer. The Chrome UX Report release notes on Chrome for Developers record that LCP image subparts and LCP resource types arrived in the CrUX API in January 2025, that the ECT dimension was retired from BigQuery in the same release, and that the old CrUX Dashboard was deprecated at the end of November 2025. Separately, the soft navigations work reached Chrome 151, letting single page apps attribute LCP, INP and CLS to individual route changes rather than one endless page view. That documentation is explicit that how soft navigations will be reported in CrUX is still undecided, so it does not affect your Search Console numbers yet.
If you were told a new metric landed this year, ask which one. There isn't one.
How to fix a slow LCP
Almost every bad LCP is a discoverability problem. The top fixes guide on web.dev puts three things first: make sure the LCP resource is visible in the HTML source rather than injected by script, mark it fetchpriority="high", and cut Time to First Byte with a CDN that caches the document itself. Beyond that, aim for instant navigations using the back and forward cache or speculation rules, so the next page is already there when the click happens.
How to fix a high INP
INP breaks into three parts: input delay before your handler runs, the processing duration of the handler, and presentation delay before the next frame paints. The reported score is roughly the worst interaction on the page, with one outlier ignored per fifty interactions. The recommended fixes are yielding often so long tasks stop blocking the main thread, shipping less JavaScript in the first place, and keeping rendering updates small with a modest DOM and CSS containment. Audit your tag manager. It is usually in there.
How to fix layout shift
CLS looks at the worst burst of shifting, defined as shifts less than one second apart inside a window of at most five seconds. Set explicit width and height or an aspect ratio on every image and embed, reserve space for anything injected late such as banners and consent bars, keep the page eligible for the back and forward cache, and animate with transform instead of properties that force layout.
Where should you measure Core Web Vitals?
Field data first, always. Lab tools are for catching regressions before you ship, and web.dev is blunt that they are not a substitute for real users on real devices. The Chrome User Experience Report is the field dataset. PageSpeed Insights and the Core Web Vitals report in Search Console both read from it, and the web-vitals JavaScript library gives you your own numbers with far less delay than a 28 day rolling window. Chrome DevTools and Lighthouse cover the lab side. Use both, but only field data decides whether you pass.
Do Core Web Vitals still affect Google rankings?
Google Search Central still documents Core Web Vitals as part of page experience, describing them as metrics that measure real user experience and saying they align with what its core ranking systems seek to reward. That is deliberately softer than a ranking factor. Treat it as a tiebreaker between pages that are otherwise comparable, and as something that plainly affects conversions whatever Search does. The same logic applies to the rest of your technical foundation, which is what our AI readiness checker looks at.
One thing worth saying to anyone chasing a perfect score: passing all three thresholds at the 75th percentile is the finish line. There is no bonus tier above it. Once you are green, the next hour is better spent on whether crawlers can reach the page at all, which is a five minute check in your robots.txt.