a practical field guide to core web vitals in 2026

Core Web Vitals are Google's attempt to turn the fuzzy idea of "a good page experience" into three concrete, measurable numbers. They are not the only thing that matters for a website, but they are an honest proxy for how a page feels to a real person on a real device: how quickly the main content appears, how responsive the page is when you tap or click, and how steady the layout stays while everything loads. This guide walks through all three metrics as they stand in 2026, the thresholds you should aim for, and the techniques we reach for most often when improving them.

the three metrics that count

As of 2024, the three Core Web Vitals are Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). INP formally replaced First Input Delay (FID) in March 2024, which was a meaningful change: FID only measured the delay before the browser started processing your first interaction, while INP measures the full latency of interactions across the whole visit. In practice, INP is a much harder and more honest test of responsiveness.

Each metric has three bands. To be rated "good," a page should meet the following thresholds at the 75th percentile of real visits:

• LCP: 2.5 seconds or less (good), up to 4.0 seconds (needs improvement), slower than that is poor.
• INP: 200 milliseconds or less (good), up to 500 milliseconds (needs improvement), slower is poor.
• CLS: 0.1 or less (good), up to 0.25 (needs improvement), higher is poor.

The 75th-percentile detail matters. You are not graded on your fastest visit or your average — you are graded on what three-quarters of your visitors actually experience, which includes mid-range phones on congested networks.

largest contentful paint: show the main thing fast

LCP measures how long it takes for the largest element in the viewport — usually a hero image, a video poster, or a big block of text — to render. A slow LCP almost always comes down to one of four causes: a slow server response, render-blocking CSS or JavaScript, slow-loading resources, or client-side rendering that delays the content.

The techniques that move LCP the most, roughly in order of impact:

• Serve the document quickly. Use a CDN, cache HTML where you can, and keep your Time to First Byte low.
• Preload the LCP image and serve it in a modern format (AVIF or WebP) at the correct dimensions. Never let a 3000px image render into a 600px slot.
• Mark the LCP image with fetchpriority="high" and avoid lazy-loading anything that is visible on first paint.
• Inline critical CSS and defer the rest so the browser is not blocked from painting.

interaction to next paint: stay responsive

INP is the metric most teams underestimate. It captures the time from a user interaction — a tap, a click, a key press — to the next frame the browser paints in response. A high INP feels like a sluggish, unresponsive page: you tap a button and nothing happens for a beat. The usual culprit is JavaScript that monopolises the main thread.

To bring INP down, the goal is to keep the main thread free to respond:

• Break up long tasks. Any task that runs longer than 50 milliseconds blocks interaction; split heavy work into smaller chunks and yield back to the browser with scheduler.yield() or a deferred callback.
• Ship less JavaScript. Code-split, remove unused dependencies, and prefer native browser features over heavy libraries.
• Move non-urgent work out of the way — into a web worker, or behind requestIdleCallback — so it does not compete with the user's input.
• Avoid large, synchronous layout recalculations triggered by reading and writing the DOM in tight loops.

cumulative layout shift: keep things still

CLS measures unexpected movement: content that jumps as images, fonts, or embeds load in. It is one of the most fixable vitals, because nearly every shift has a clear cause. Always set explicit width and height attributes (or a CSS aspect-ratio) on images and video so the browser can reserve space before the file arrives. Reserve space for anything injected late, including embeds and dynamic widgets. Use font-display: optional or carefully matched fallback fonts to avoid text reflowing when a web font loads. And never insert content above existing content unless it is in direct response to a user action. For a deeper treatment — reserving space for ads, taming font swaps, and debugging shifts with the Layout Instability API — see our guide to mitigating cumulative layout shifts.

measuring the right way: lab versus field

There are two ways to measure these metrics, and confusing them leads to wasted effort. Lab data comes from synthetic tools like Lighthouse: a single run in a controlled environment, excellent for debugging but not representative of your real audience. Field data — also called Real User Monitoring — comes from actual visitors, and it is what Google uses for ranking via the Chrome User Experience Report (CrUX).

The practical workflow is to use lab tools to diagnose and fix a specific problem, then watch field data over the following weeks to confirm the fix reached real users. Note that INP and CLS are accumulated across the whole session, so they often cannot be fully captured in a single Lighthouse run — field data is essential for both.

a worked example: auditing this very site

Rather than leave the advice abstract, here is the audit we ran on this site while writing this guide. On 4 July 2026 we ran Lighthouse 12 against the production homepage and a production article page — mobile emulation, simulated slow-4G throttling, cold cache. These are lab numbers, with all the caveats from the previous section.

The shape of these numbers tells a story worth reading. The 40 ms TTFB is the CDN doing its job — static HTML served from a nearby edge cache. The zero TBT reflects a site that ships almost no JavaScript, and the zero CLS is the payoff of reserving space for everything (the subject of our CLS guide). A static site gets these three nearly for free.

But LCP missed the 2.5-second threshold, and Lighthouse pointed at exactly one culprit: a render-blocking web-font stylesheet, estimated at roughly 870 ms of the delay. The root cause was self-inflicted and instructive — our CSS loaded the Google Fonts stylesheet via @import. That creates a sequential request chain: the browser cannot even discover the font CSS until the main stylesheet has downloaded, so two round-trips that could happen in parallel happen one after the other. On a throttled mobile connection, that chain is most of the gap between 3.0 s and the threshold.

The fix, which ships alongside this article: drop the @import, load the font stylesheet from a <link> in the document head so it downloads in parallel with the main CSS, and add preconnect hints so the connections to the font origins are already warm when the requests fire:

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Inter:...&display=swap">

We will watch the field data over the coming weeks to confirm the lab prediction holds for real visitors — exactly the diagnose-in-lab, verify-in-field loop described above. The honest lesson: even a deliberately minimal static site accumulates performance debt, and the audit is worth re-running every time you change how anything loads.

instrumenting real users without a vendor

You do not need a paid RUM product to see field data. Google's open-source web-vitals library is a few kilobytes and reports the real metrics from real sessions to wherever you point it:

import { onLCP, onINP, onCLS } from "web-vitals";

function send(metric) {
  navigator.sendBeacon("/vitals", JSON.stringify({
    name: metric.name,
    value: metric.value,
    page: location.pathname
  }));
}

onLCP(send); onINP(send); onCLS(send);

Even logging these to a simple endpoint and eyeballing the 75th percentile weekly puts you ahead of most teams, because you are looking at the same distribution Google scores you on. For sites with enough Chrome traffic, the CrUX dashboard gives you the official view for free — but your own beacon covers every browser and every page, including the ones too quiet to appear in CrUX.

a sensible order of operations

If you are staring at a report full of red, resist the urge to fix everything at once. Start with the metric that is furthest from its threshold and affects the most pages, usually LCP. Ship one focused improvement, measure its effect in the field, and only then move to the next. Performance work compounds: a faster document helps LCP, less JavaScript helps both INP and LCP, and disciplined layout helps CLS. Treat Core Web Vitals not as a one-time audit to pass but as a budget to maintain — a number you check every time you ship.