How to pass Core Web Vitals in 2026
Core Web Vitals are the closest thing search has to a public health check: three metrics, three thresholds, measured on your real visitors and folded into how Google ranks you. In 2026 the bar hasn't moved — LCP ≤ 2.5s, CLS ≤ 0.1, INP ≤ 200ms — but the stakes have, because the same speed signals now decide whether AI engines can fetch and cite you before they time out. This guide walks each metric in the order failures actually happen: what it measures, what breaks it, and the fix that moves the field data — not just your lab score.
What are Core Web Vitals, and what do you need to pass in 2026?
Core Web Vitals are three user-experience metrics — LCP for loading, CLS for visual stability, and INP for responsiveness. To pass in 2026 you need all three green at the 75th percentile of real visits: LCP ≤ 2.5s, CLS ≤ 0.1, and INP ≤ 200ms. Fail one, and you fail the assessment.
LCP, Largest Contentful Paint, measures loading — the time from the start of the load until the largest image or text block in the viewport finishes rendering. It stands in for how long a user waits to see your page's main content.
CLS, Cumulative Layout Shift, measures visual stability — how much visible content moves unexpectedly while the page loads. The button that jumps away just as you reach for it is CLS costing you points.
INP, Interaction to Next Paint, measures responsiveness — the delay between a tap, click, or keypress and the screen updating in response. It replaced FID in March 2024 and is the metric most sites now struggle with.
Passing means the 75th percentile — three-quarters of visits must beat the threshold. In other words, the experience of your slowest quarter of users is what defines your Core Web Vitals score.
- LCP (loading) ≤ 2.5s — the largest image or text block in the viewport paints.
- CLS (visual stability) ≤ 0.1 — visible content doesn't jump as the page loads.
- INP (responsiveness) ≤ 200ms — taps and clicks update the screen without lag.
- Pass = all three green at the 75th percentile of real visits.
Field data or lab data — which one actually decides if you pass?
Field data decides. Google scores Core Web Vitals from the Chrome UX Report — anonymized measurements from real Chrome users over a rolling 28-day window. Lab tools like Lighthouse simulate a single load on one machine; they're for debugging, not for judging whether you pass. Trust the field, use the lab to explain it.
A green Lighthouse score on your fast laptop can hide a failing experience on a mid-range phone — field data captures the devices and networks your lab test never sees.
Search Console's Core Web Vitals report is that field data grouped by URL pattern — the fastest way to see which templates are failing and for how many users.
Lab data is still essential, but as a microscope, not a verdict — it reproduces one load so you can trace exactly which resource or script drove the number. It's one layer of a full technical SEO audit.
The 28-day window means fixes don't show up instantly — ship the change, then watch the field curve move over the following weeks rather than refreshing Lighthouse.
- Field data (CrUX) — real Chrome users, 28-day rolling window — is what Google scores.
- Search Console's CWV report groups that field data by URL pattern.
- Lab data (Lighthouse) simulates one load — use it to debug, not to judge.
- Fixes surface in the field over weeks, not instantly.
How do you fix a failing LCP?
LCP fails when the largest element in the viewport — usually a hero image or headline — takes longer than 2.5s to render. The usual culprits are a slow server response, render-blocking CSS or JavaScript, an unoptimized or lazy-loaded hero image, and client-side rendering. You fix the delivery path to that one element.
Start with TTFB, time to first byte — if the server takes a second to respond, LCP can never be fast, so a CDN, caching, and edge rendering are the first lever to pull.
Never lazy-load the LCP element — putting loading='lazy' on your hero image is the most common self-inflicted LCP failure; mark it high priority with fetchpriority='high' instead.
Serve the hero in a modern format like AVIF or WebP, sized to its container, and preload it so the browser starts fetching before it finishes parsing your CSS.
Render-blocking resources delay the paint — inline critical CSS, defer non-critical JavaScript, and self-host fonts so a third-party server isn't sitting on your critical path.
- Cut TTFB with a CDN, caching, and edge rendering.
- Never put loading='lazy' on the LCP element; use fetchpriority='high'.
- Serve the hero as AVIF/WebP, sized to its container, and preload it.
- Inline critical CSS, defer non-critical JS, self-host fonts.
How do you stop layout shift and pass CLS?
CLS measures how much visible content jumps as the page loads, and you pass at ≤ 0.1. Nearly every shift traces to content that loads without reserved space — images with no dimensions, ads and embeds injected above existing content, and web fonts that swap and reflow text. Reserve the space before it fills.
Always set width and height, or a CSS aspect-ratio, on images and video so the browser reserves the box before the file arrives.
Reserve space for ads, embeds, and banners with a min-height container — the biggest shifts come from a late-loading ad shoving everything below it down the page.
Fonts cause a subtler shift — a fallback swapping to your web font reflows the text; font-display: optional plus a size-adjusted fallback keeps the swap invisible.
Never insert content above existing content unless it's in direct response to a user interaction — a cookie bar or promo dropped in at the top pushes the whole page down.
- Set width/height or aspect-ratio on every image and video.
- Reserve space for ads, embeds, and banners with a min-height box.
- Use font-display: optional and a size-adjusted fallback font.
- Never inject content above the fold except after a user interaction.
How do you fix INP, the metric most sites now fail?
INP measures the delay between every tap or click and the next frame the screen paints, and you pass at ≤ 200ms. It fails when JavaScript monopolizes the main thread — long tasks, heavy third-party scripts, and expensive framework hydration all block the browser from responding. Break the work into smaller pieces.
INP replaced FID in March 2024 and is far stricter — FID only measured the input delay of the first interaction, while INP watches every interaction all the way through to the visual update.
Long tasks are the root cause — any script that runs for more than 50ms blocks input, so break them up and yield to the main thread so the browser can respond between chunks.
Third-party scripts — tag managers, chat widgets, analytics — are the usual offenders; audit them, defer what isn't critical, and load the rest only after the first interaction.
On framework sites, hydration is the hidden cost — shipping and executing a large JavaScript bundle to make server-rendered HTML interactive; code-split, defer, and hydrate only what actually needs to be interactive.
- Break up any task over 50ms and yield to the main thread.
- Audit third-party scripts; defer or lazy-load what isn't critical.
- Code-split and defer framework hydration to what's actually interactive.
- Remember: INP watches every interaction, not just the first.
Why does page speed also decide whether AI engines cite you?
Because AI retrieval runs on a budget. ChatGPT and Perplexity fetch live pages at query time and abandon ones that are slow or heavy; Google's AI Overviews draw from an index that speed already gates. A page that takes six seconds to render is a page a crawler on a deadline simply skips.
Speed has always been a crawl signal — a fast, stable page gets crawled more deeply and more often, so more of it reaches the index that AI Overviews synthesize their answers from.
The same field-data discipline that passes Core Web Vitals makes your page cheaper to fetch and parse, which keeps you inside the candidate set generative engines actually read — the foundation of GEO.
Speed is necessary, not sufficient — a fast page still has to match intent and answer the question, which starts upstream with keyword research that ranks and quotable, extractable answers.
Put together, performance is now a two-audience investment: it lifts classic rankings and it decides whether you're even reachable when a model assembles an answer — which is exactly how you get cited by ChatGPT, Perplexity and AI Overviews.
- Live-retrieval engines (ChatGPT, Perplexity) abandon slow fetches.
- AI Overviews draw from an index that speed already gates.
- Fast, stable pages get crawled deeper and more often.
- Speed is necessary, not sufficient — intent and extractability still decide.
Let the agent run this playbook for you
Start free