Core Web Vitals in 2026: LCP, INP and CLS targets and how to hit them

The 2026 Core Web Vitals targets haven't moved since 2024. Largest Contentful Paint (LCP) under 2.5 seconds. Interaction to Next Paint (INP) under 200 milliseconds. Cumulative Layout Shift (CLS) under 0.1. Google measures each one at the 75th percentile of real visits, split by mobile and desktop, not a single lab run. And INP became the official interactivity metric in 2024, replacing First Input Delay (FID), which is worth knowing if your team is still optimizing against the old one.

What Core Web Vitals measure in 2026

LCP, INP and CLS, defined

LCP measures loading performance: how long it takes the largest visible element, usually a hero image or headline block, to render. The good threshold is 2.5 seconds from the moment the page starts loading.

INP measures interactivity. It's the time between a user's click, tap or keypress and the next visual update on screen, and the good threshold is 200ms or less. INP replaced FID as the official Core Web Vital in 2024, after a year as an experimental metric. FID only ever captured the delay before the browser started processing an input, not the full time to a visible response, which left a real gap in what teams were optimizing for.

CLS measures visual stability, meaning how much content shifts around unexpectedly as a page loads. The good threshold is 0.1 or less. Go above that and users are reliably tapping the wrong button, or losing their place mid-paragraph.

The 75th percentile, field data rule

Lighthouse and other lab tools run a single simulated page load. Useful for debugging, but not for compliance. Google's actual measurement comes from the Chrome User Experience Report (CrUX): real field data from real visits. A page only counts as "good" for a given metric once 75 percent of its page loads meet that metric's threshold, tracked separately for mobile and desktop. So a page can score well in Lighthouse and still show as failing in Search Console, if mobile users on older devices are dragging the field data down.

Why Core Web Vitals affect Google Search results

Core Web Vitals aren't a standalone ranking factor with a fixed point value. Google describes them as part of a broader page experience signal that aligns with what its core ranking systems already reward: relevant, well-built pages tend to load and respond quickly anyway. Fixing Vitals rarely moves a page from position 20 to position 2 on its own. But a page that fails badly enough to frustrate users is competing at a disadvantage no matter what the algorithm rewards directly.

Three tools are worth checking regularly. Search Console's Core Web Vitals report groups URLs by status and flags regressions. PageSpeed Insights shows both lab and field data for a single URL. The CrUX dataset itself is best for site-wide trend tracking. Treat lab scores as a debugging aid and field data as the source of truth: a page can look fast in one Lighthouse run on a fast connection and still fail its 75th-percentile threshold once real mobile traffic on slower networks gets counted.

How to hit your LCP and INP targets

Ship the LCP image correctly

The single biggest lever for LCP is making sure the browser can discover the hero image immediately. It needs to sit in the initial HTML, either as a standard <img src> or a <link rel="preload">, not injected later by JavaScript through a data-src attribute. Add fetchpriority="high" and drop loading="lazy" on that one image. This matters more than it sounds: 73 percent of mobile LCP elements are images, yet only 15 percent of sites currently use fetchpriority to prioritize them.

Cut time to first byte

A fast image doesn't help much if the HTML itself is slow to arrive. Time to first byte (TTFB) sets the floor for every metric downstream of it: LCP can't start its clock until the document begins arriving, so a slow server response pushes every later measurement back with it. Serving pages from a CDN, geographically close to the visitor, cuts TTFB and gives every other metric a head start. Only about a third of HTML requests are currently served from a CDN, which is a real opportunity for most sites, not a niche optimization. Static generation, or incremental static regeneration, where the page is built ahead of the request instead of on it, removes most of the server-side work from the critical path entirely.

Use bfcache for near-instant repeat visits

Back/forward cache (bfcache) restores a fully rendered page from memory instead of reloading it, which produces a near-zero LCP on repeat navigation. Staying bfcache-eligible, no unload handlers, no Cache-Control: no-store on pages that don't need it, is one of the cheapest wins available.

Keep the main thread free for INP

INP problems are almost always JavaScript problems. Break long tasks (anything over 50ms) into smaller chunks so the browser can respond to a click in between; the Scheduler API helps here where it's available. Ship less JavaScript overall, and use code-splitting so a page only loads what it needs. Avoid forced synchronous layouts. Use CSS containment to stop off-screen content from competing for render time.

What Next.js gives you by default

If your stack is Next.js, part of this is already handled. The built-in next/image component auto-sizes statically imported images and supports both fetchpriority and native lazy loading, which covers a meaningful share of LCP work without custom code. It doesn't fix TTFB, JavaScript payload or CDN placement on its own; those still need deliberate configuration. For a fuller walkthrough of what to check site-wide, see our Next.js technical SEO audit checklist.

How to hit your CLS target

Set an explicit width and height, or a CSS aspect-ratio, on every image and embed. This single fix addresses the most common cause of layout shift: 66 percent of pages ship at least one unsized image that pushes content around as it loads. Staying bfcache-eligible helps here too. It produced the largest industry-wide CLS improvement on record after its 2022 rollout, since a restored page has nothing left to shift. And animate the transform CSS property instead of margin, border width or other properties that affect layout: pages that animate layout-affecting properties show CLS problems at almost twice the rate of typical sites.

Frequently asked questions

What are the Core Web Vitals thresholds in 2026?

LCP within 2.5 seconds, INP at 200 milliseconds or less, and CLS at 0.1 or less, each measured at the 75th percentile of real page loads.

Do Core Web Vitals affect Google rankings?

They're one input into Google's page experience signal, which the core ranking systems factor in alongside relevance. They are not a standalone ranking override.

What replaced First Input Delay (FID)?

Interaction to Next Paint (INP) became the official interactivity Core Web Vital in 2024, replacing FID.

Does Next.js improve Core Web Vitals automatically?

The built-in Image component auto-sizes statically imported images to prevent layout shift and supports fetchpriority and lazy loading, but TTFB, JavaScript payload and CDN placement still need deliberate configuration.

Conclusion

The thresholds are fixed and easy to check: 2.5 seconds, 200 milliseconds, 0.1, all measured against real visits rather than a single test run. The highest-leverage fixes are the ones with the most room left industrywide: making the LCP image discoverable and prioritized, moving HTML closer to users, keeping pages bfcache-eligible, and giving every image explicit dimensions. None of it requires a rebuild, just a focused pass through the pages that matter most. If you want that pass done for you, it's part of our web development work.