Core Web Vitals Explained
Core Web Vitals are three metrics Google uses to score real-user experience: Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability. A page passes when all three hit their “good” threshold at the 75th percentile of field traffic. They are part of Google’s page experience signals and affect ranking.
The three metrics and their 2026 thresholds
The thresholds below are the “good” bar. To pass, you need this value or better for the 75th percentile of page loads — meaning three out of four real visits, not a single lab run.
| Metric | Measures | Good | Needs work | Poor |
|---|---|---|---|---|
| LCP | Loading — when the largest content element finishes painting | < 2.5s | 2.5s–4.0s | > 4.0s |
| INP | Responsiveness — slowest interaction across the session | < 200ms | 200ms–500ms | > 500ms |
| CLS | Visual stability — how much the layout shifts unexpectedly | < 0.1 | 0.1–0.25 | > 0.25 |
INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. It is harder to pass because it accounts for every interaction on the page, not just the first, and it measures the full delay from input to the next paint — not just the queueing time.
LCP: what hurts it and how to fix it
LCP marks the moment the largest visible element — usually a hero image, a heading, or a banner — finishes rendering. Four sub-parts add up to it: time to first byte, resource load delay, resource load time, and render delay.
What hurts LCP:
- A slow server response (high TTFB caps how low LCP can go).
- The LCP image being lazy-loaded, discovered late, or served oversized.
- Render-blocking CSS and synchronous JavaScript in the
<head>. - Web fonts that block text paint.
How to improve it:
- Get TTFB under ~800ms with edge caching and a CDN close to users.
- Set
fetchpriority="high"on the LCP image and never lazy-load it. - Serve AVIF or WebP sized to the layout, and preload the LCP resource.
- Inline critical CSS and defer the rest.
INP: what hurts it and how to fix it
INP measures how quickly the page responds across the whole visit. A single slow tap or click can fail the metric. The delay breaks into input delay, processing time, and presentation delay.
What hurts INP:
- Long JavaScript tasks blocking the main thread (anything over 50ms).
- Heavy third-party scripts — tag managers, chat widgets, analytics.
- Large, synchronous event handlers and expensive re-renders.
How to improve it:
- Break up long tasks; yield to the main thread with
scheduler.yield()orsetTimeout. - Code-split and defer non-critical JavaScript; audit and cut third-party tags.
- Move work off the click path — debounce, memoize, or push it to a web worker.
- Reduce hydration cost on framework sites with islands or partial hydration.
CLS: what hurts it and how to fix it
CLS sums the unexpected layout shifts that happen while a page loads and runs. It is a unitless score, not a time.
What hurts CLS:
- Images and videos without explicit
widthandheight. - Ads, embeds, and banners injected after first paint.
- Web fonts swapping and re-flowing text.
- Content inserted above existing content without reserved space.
How to improve it:
- Always set dimensions or a CSS
aspect-ratioon media. - Reserve space for ads, embeds, and dynamic content with min-height placeholders.
- Use
font-display: swapwith a size-matched fallback to limit reflow. - Apply CSS transforms for animation instead of properties that trigger layout.
Lab data vs. field data
Lighthouse and WebPageTest run in a controlled lab and give you a trace — the waterfall, the long tasks, the unused bytes — which is how you find the cause of a problem. But the data that scores your page is field data: the Chrome User Experience Report (CrUX) and your own Real User Monitoring, segmented by device and connection. A 95 lab score with a failing CrUX LCP just means your test device is faster than your visitors’ phones. Diagnose in the lab, but always measure progress against the field at the 75th percentile.
Where to start
Pull your CrUX or RUM data first and find which of the three metrics fails and on which templates. Fix the one that fails for the most users, confirm the field number moves, then set a budget in CI so it does not regress. If you want a second set of eyes on what is slow and what it will take to fix, get in touch and send us a URL.
