The Core Web Vitals 2026 Guide: How to Hit Green on LCP, INP, and CLS

Each Core Web Vital has three buckets: good, needs improvement, and poor. A page passes a vital when its 75th percentile across the previous 28 days lands in the good bucket. Both the percentile and the window matter — fixing your LCP today does not move your CrUX dashboard until 75% of pageviews in the next four weeks have already loaded the fixed version, which is why teams who deploy a Friday afternoon hot-fix often cannot see the win until late next week.

The current thresholds are LCP at or below 2.5 seconds for good and 4.0 seconds for the upper bound of needs improvement; INP at or below 200 milliseconds for good and 500 milliseconds for the upper bound; and CLS at or below 0.1 for good and 0.25 for the upper bound. Search Console lags lab tools because of the rolling field-data window, so validate a fix immediately in lab or first-party RUM data before waiting for the aggregate report to move.

There is no "average" in CrUX. Google reports the 75th percentile because it correlates better with abandonment than the median — fast median sites with bad p75 still feel sluggish to a quarter of users, and Google ranks based on what those users experience. When Lighthouse shows you a 1.4-second LCP and CrUX shows you a 3.8-second LCP, both are right; Lighthouse is showing the lab device on a fast connection, and CrUX is showing the actual long tail of phones, networks, and cold caches.

LCP measures the render time of the largest above-the-fold element. Ninety percent of the time that element is either a hero image or the first paragraph of body text, and the long pole on the network waterfall is the request that fetches it. The cheapest LCP win in any modern stack is preloading that single resource. Add for image-driven heroes and the LCP element starts downloading concurrently with the HTML, instead of waiting for the parser to discover it.

Next.js 15 makes this easy with the priority prop on next/image, which emits the preload tag for you. SvelteKit and Astro both ship native preload helpers; Vue's official image plugin (@nuxt/image does the same. The risk is over-preloading: every preloaded resource competes for early bandwidth, so reserve the tag for the single LCP element and nothing else. Auditing a site with twelve preloads is its own performance tax, and Chrome will warn in DevTools when a preloaded resource is not used within a few seconds.

After preload, the next big lever is image format. AVIF beats WebP by roughly 20-30% at equivalent visual quality and is supported in every modern browser. The element with WebP and JPEG fallback is fine for compatibility, but in 2026 the WebP-only sites are leaving bytes on the table. If you are on Cloudinary, imgix, Vercel Image Optimization, or any other on-the-fly transformer, switching the default output to AVIF takes one config flag.

The third lever is CSS render-blocking. Critical CSS is back, but not in the 2018 sense. Modern frameworks (Astro, SvelteKit, Next.js App Router) inline critical CSS automatically when you let them. The footgun is when developers import a 200KB design system stylesheet at the root layout to keep imports tidy — that single import becomes render-blocking on every route. Split the stylesheet by route group, lean on CSS modules or Tailwind's JIT, and treat any CSS file over 50KB as suspect.

If you are still failing LCP after preload, AVIF, and CSS triage, inspect third-party blocking scripts. Google Tag Manager loaded synchronously in can block render. Defer non-critical tags or isolate them behind an appropriate worker/integration, then measure the change instead of assuming a fixed gain.

INP (Interaction to Next Paint) measures the time between any user interaction and the next visual frame. It captures the worst single interaction during a page's lifetime, not the median, which is why a single click handler that runs 800ms of synchronous work tanks the metric even if the rest of the page is buttery smooth. INP is also measured at p75 across CrUX, so the long-tail lesson from LCP applies again — your local fast laptop is a useless reference.

The most common INP regressions in 2026 come from React. Specifically, from class components or memoized function components that pass large props through deep trees and re-render on every keystroke or scroll. React 19's compiler helps, but only if you actually run the compiler in production builds. Check your next.config.js for experimental.reactCompiler: true (or the equivalent flag in your framework), confirm the production bundle includes the compiled output, and verify in React DevTools' Profiler that re-render counts on the suspect interaction are sane.

The second common cause is hydration cost on routes that look static. Server Components in Next.js App Router help here, but only if you actually use them — adding "use client" at the layout level forces the entire subtree into client rendering and re-hydrates on every navigation. Audit your "use client" directives and push them as far down the tree as possible. A blog post template with one client island for a copy-link button should not hydrate the entire article.

On non-React stacks the dynamic is similar. SvelteKit's +page.svelte files only hydrate when they include event handlers or stateful logic — keep them dumb when possible. Vue 3's is fast at runtime but expensive at hydration when components are large; Vue's Vapor mode (stable in 2026) helps. Astro's client:idle and client:visible directives are the cleanest way to defer hydration entirely on island architectures.

Long tasks (>50ms blocking the main thread) are the proximate cause of INP failures. Use the web-vitals library's onINP callback to attribute long tasks to specific event handlers, and DevTools' Performance panel to see which functions are running. The fix is almost always one of: break the work into chunks with requestIdleCallback; move the work to a Web Worker; or remove a third-party script that is hijacking the main thread. Stripe's checkout SDK is a frequent culprit on e-commerce sites — load it on demand, not at page load.

Cumulative Layout Shift measures how much visible content jumps around during a page's lifetime. A CLS of 0.1 means roughly 10% of the visible viewport shifted unexpectedly. Three patterns cause 95% of CLS failures: images without intrinsic dimensions, ad slots that resize after load, and font swaps that re-flow text after the layout has settled.

Image dimensions are the easiest to fix. Always set width and height attributes on tags, even when CSS sizes the image responsively. Browsers use the ratio to reserve space before the bytes arrive. next/image and equivalent components handle this for you when you provide width and height props. Aspect-ratio CSS (aspect-ratio: 16 / 9) works as a fallback for images you cannot dimension at build time.

Ad slots are the genuinely hard case. Programmatic ads (Google Ad Manager, Prebid stack) can return any of several sizes, and reserving space for the largest is wasteful. The right pattern is a min-height container sized to the most common slot dimension, with skeleton styling so the empty state does not feel like a layout bug. CLS counts shifts of off-screen elements that scroll into view, so even ads below the fold contribute when the user scrolls.

Font swap is the third pattern. font-display: swap shows a fallback while a custom font loads, then swaps it in once it arrives — that swap is a layout shift if metrics differ. Use font-display: optional if you can tolerate the fallback for slow connections, or use the new size-adjust, ascent-override, and descent-override font-face descriptors to match metrics between fallback and custom font. Tools like Fontaine and next/font automate this.

Once you have the basics, instrument CLS with web-vitals attribution. The loadState field tells you whether the shift happened during initial load or after user interaction; the largestShiftSource field identifies the responsible DOM node. A delayed newsletter banner that pushes the page down is a representative pattern this reveals.

Each framework has its own quirks and escape hatches. The tactics below are ordered roughly by expected impact, but every change should be measured on the target page.

Next.js (App Router): Confirm next/image is everywhere — including OG-style decorative images, not just hero shots. Confirm priority is set on the LCP image only. Push "use client" directives down the tree. Use next/font for Google Fonts — never to fonts.googleapis.com directly. Enable PPR (experimental.ppr) for routes with mixed static/dynamic content. Run next build --profile and inspect .next/analyze to find oversized client bundles.

SvelteKit: Enable precompress: true in adapter-node or rely on Vercel/Netlify auto-Brotli. Mark expensive components as lazy with patterns. Use forms instead of client-side fetch. Image optimization via @sveltejs/enhanced-img is mandatory. Long-poll your route splits — SvelteKit's default code splitting is good but not perfect for large monorepos.

Astro: Use client:idle or client:visible on every island. The default client:load defeats the architecture. Image component is excellent — no excuse for unoptimized images. Astro's View Transitions API gives you instant-perceived navigation; combine with prefetch for sub-100ms perceived navigation on internal links. Pay attention to the astro:assets cache headers in production.

Vue 3 / Nuxt: Vapor mode is stable in 2026 and produces meaningfully smaller bundles for component-heavy apps. Use with format=webp,avif. Lazy-hydrate with lazyHydrate: true on slow components. Disable experimental.payloadExtraction only if you have profiled and confirmed it is hurting — it is on by default for a reason.

Remix: Resource routes are great, but they bypass Remix's loader optimizations — be deliberate about which routes use them. The new single-fetch behavior in Remix v3 dramatically reduces network requests on route transitions; opt in via future.unstable_singleFetch. for navigation prediction.

The three measurement modalities answer different questions. Lab tools (Lighthouse, PageSpeed Insights, WebPageTest) tell you what is technically possible on a given device. CrUX tells you what your users actually experience at p75 across the last 28 days. RUM (web-vitals.js piped to your own analytics) tells you what individual users on individual page templates are experiencing in the last hour.

Lab tools are useful for regression testing — wire them into CI and fail builds when LCP regresses by more than 100ms. WebPageTest's filmstrip view is unmatched for visualizing what a slow LCP feels like; their custom-metric scripting lets you track tail-of-load resources. Lighthouse CI is free and integrates with GitHub Actions in fifteen minutes.

CrUX is the canonical data source for ranking decisions, but it is not granular. The CrUX API returns p75 by URL and by origin, and CrUX BigQuery has full distributions you can query with SQL. The dashboard at g.co/CrUXDash is free, public, and the right place to monitor month-over-month trends.

RUM is where you debug the long tail. A simple web-vitals integration plus a tiny POST endpoint plus a dashboard (Grafana, Datadog RUM, Sentry, or a homemade solution on top of ClickHouse) is usually enough. The big wins from RUM come from segmenting by route, device class, and network — once you know that 90% of your INP failures come from /checkout on Android with 3G, you have a bug to fix instead of a metric to chase.

Consider a hypothetical Next.js marketing page with a 4.1s field LCP after the obvious AVIF, below-fold lazy-loading, and font-display work is complete. The sequence below illustrates diagnosis; it is not presented as a CheckFast customer result.

First inspect whether the LCP image preload is present in the server HTML. A client-only wrapper can delay discovery even when an image component is marked high priority. Move unrelated experimentation state into a child island, then compare the network waterfall and LCP across controlled runs.

Next verify compression at the actual edge response rather than trusting a framework default. A custom proxy or edge function can override Brotli with gzip. Remove accidental header overrides and measure transferred bytes and LCP again.

Finally inspect synchronous third-party scripts in. Load non-critical trackers after interaction or idle time and confirm in the Performance panel that they no longer block the main thread. Validate the combined result in lab data immediately, then use first-party RUM and the later CrUX window to confirm real-user improvement.