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 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.