If you last looked at Core Web Vitals in 2022, the playing field has shifted under your feet. FID is gone, replaced by INP — a much stricter metric that punishes the kind of lazy JavaScript most sites still ship. Google now uses Core Web Vitals as a ranking signal across all queries, not just mobile, and the thresholds keep tightening as the web gets faster. Here's the state of play in 2026, what 'good' looks like, and the fixes that move the needle.
LCP — Largest Contentful Paint
LCP measures how long the largest visible element on the page (usually a hero image or headline) takes to render. Google's threshold for 'good' is still under 2.5 seconds, but in practice you should be aiming below 1.8 — the gap between you and a competitor with 2.4s LCP is enough to matter when both pages otherwise look comparable.
Most LCP failures we audit come from one of three causes. First, an unoptimised hero image — a 1.2MB JPG when a 90KB AVIF would look identical. Second, render-blocking JavaScript: a marketing script in the <head> tag that delays the page paint by 400ms for no good reason. Third, fonts loaded synchronously with no fallback, so the page waits on a font download before showing any text. All three are fixable in an afternoon.
INP — Interaction to Next Paint
INP replaced FID as the responsiveness metric in March 2024, and this is where most modern sites are quietly failing. INP measures the worst case (98th percentile) lag between any user interaction — click, tap, keystroke — and the visible response. Google's 'good' threshold is under 200ms; we recommend treating 150ms as the real target.
INP problems are almost always caused by long JavaScript tasks blocking the main thread. The biggest offenders we see in 2026: heavy hydration on React/Next.js sites, third-party analytics tags that run on every interaction, and overly clever scroll listeners. The fix is usually unglamorous — debounce, split bundles, defer non-critical scripts, and make sure your framework's hydration strategy isn't running a full re-render every time the user touches the page.
CLS — Cumulative Layout Shift
CLS is the metric most teams already understand: how much the page jumps around as it loads. The threshold (under 0.1) hasn't changed, but the way Google measures it has tightened. Layout shifts that happen after user interaction (e.g. an image loading after you've started scrolling) now count more heavily than they used to.
The fixes are mostly hygiene work. Set explicit width and height on every image and embed. Reserve space for ads and lazy-loaded modules with min-height. Avoid injecting cookie banners and 'wait, are you sure?' modals after the page has loaded — pre-render them invisibly and toggle visibility instead. If you're still getting CLS warnings after that, it's usually a web font swap; preload the font and set font-display: optional rather than swap.
What to ignore
A lot of breathless SEO content in 2026 is still trying to sell you on 'the new Core Web Vitals' — TTFB optimisation, INP sub-metrics, render-blocking budgets, the works. Most of it doesn't matter for ranking. Google has been clear that LCP, INP, and CLS are the three that count, and that getting all three into 'good' is dramatically more important than squeezing the last 50ms out of any one of them. Optimise for the three, then stop.
The cheapest wins
If you're starting from a site with red Core Web Vitals scores, the highest-leverage fixes in order are usually: (1) convert hero images to AVIF and set explicit dimensions; (2) defer or remove third-party scripts you no longer need; (3) preload your primary web font; (4) audit your JavaScript bundle and split anything over 100KB. Most clients see all three metrics move into the green within a single week of focused work — well before any ranking benefit kicks in.
If you'd rather not do this yourself, our Technical SEO service includes a full Core Web Vitals audit and implementation of the fixes. We benchmark before, after, and again at 30 days to make sure the gains stick under real-world traffic.