Core Web Vitals advice ages faster than most SEO content, because the underlying metrics themselves have changed. If your mental model still includes First Input Delay (FID), it's out of date — FID was retired in favor of Interaction to Next Paint (INP) back in March 2024, and INP is now the metric most sites fail.
Here's what actually matters in 2026, and what to fix first.
The three metrics, current thresholds
| Metric | Measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Loading speed of the main content | ≤ 2.5s | 2.5s – 4.0s | > 4.0s |
| INP (Interaction to Next Paint) | Responsiveness to user interaction | ≤ 200ms | 200ms – 500ms | > 500ms |
| CLS (Cumulative Layout Shift) | Visual stability during load | ≤ 0.1 | 0.1 – 0.25 | > 0.25 |
These are field thresholds — measured from real Chrome users via the Chrome User Experience Report (CrUX), at the 75th percentile. A page that looks fast in a single Lighthouse lab test can still fail in the field if real users on slower devices or networks have a worse experience than your test environment.
LCP: usually a resource-loading problem
LCP most often fails for one of three reasons:
- The LCP element itself loads late — commonly a hero image that isn't preloaded, or that's discovered only after a render-blocking script executes.
- Server response time is slow — a high Time to First Byte (TTFB) delays everything downstream, including LCP.
- Render-blocking CSS or JavaScript delays paint even after the resource is available.
The highest-leverage fix on most sites is adding a <link rel="preload"> for the actual LCP image (not a placeholder) and making sure it isn't lazy-loaded — lazy-loading the LCP element is a surprisingly common self-inflicted regression.
INP: almost always a third-party script problem
INP measures the delay between a user interaction (click, tap, keypress) and the next visual update. In our audits across client sites, the single largest INP contributor is consistently third-party JavaScript: chat widgets, ad tags, A/B testing scripts, and analytics snippets that run long tasks on the main thread at exactly the moment a user tries to interact with the page.
Practical fixes:
- Audit and trim third-party scripts. Every widget has a cost; measure it before assuming it's worth keeping.
- Load non-critical scripts with
deferor as a module, and delay anything not needed for the initial interaction until after first input or a few seconds of idle time. - Break up long JavaScript tasks on your own code using
scheduler.yield()or manual chunking, so a single task doesn't block the main thread for the full duration of an interaction.
CLS: usually images, ads, and fonts
Cumulative Layout Shift almost always traces back to one of three causes:
- Images or embeds rendered without explicit
widthandheightattributes (or a CSSaspect-ratio), so the browser doesn't reserve space before the resource loads. - Ad slots that resize after their creative loads.
- Web fonts that swap in with a noticeably different size than the fallback font, shifting surrounding text.
Setting explicit dimensions on every image and embed, reserving fixed-height ad containers, and using font-display: optional or matching fallback font metrics closes most of the gap.
How much does this actually matter for rankings?
Google has been consistent since Core Web Vitals launched: they're a minor ranking factor relative to content relevance, acting more as a tiebreaker between pages that are otherwise comparably relevant than as a mechanism to outrank fundamentally better content. Chasing a perfect Lighthouse score on a page with thin or unhelpful content is a poor use of time. That said, the user-experience and conversion-rate benefits of a genuinely fast, stable page are real and typically larger than the ranking benefit alone — which is the actual reason to prioritize this work.
