Core Web Vitals: what changed in 2026 and how to fix it

The Core Web Vitals story is mostly stable in 2026, with one big change: INP (Interaction to Next Paint) fully replaced FID (First Input Delay) in March 2024, and most sites still are not optimised for it. INP is harder to hit because it measures every interaction in a session, not just the first one.

Here is what changed, and how to fix the three metrics that matter.

INP: the new interaction metric

FID measured the time between the user's first input and the browser starting to handle it. It was easy to game: if the first interaction happened after the page was idle, the score was always great.

INP fixes that. It measures the latency of every interaction across the full session (clicks, taps, keystrokes) and reports the worst case. A page that feels snappy on first click but stutters when the user scrolls or opens a menu will score badly on INP, where it would have scored fine on FID.

Targets:

• Good: < 200ms on the 75th percentile of mobile sessions.
• Needs improvement: 200-500ms.
• Poor: > 500ms. This actively hurts mobile rankings.

The fix is rarely about page weight. It is about long-running JavaScript on the main thread during input handling. Common culprits:

• Heavy click handlers that re-render large React subtrees. Fix by hoisting state, memoising children, or using useTransition to mark non-urgent updates.
• Third-party scripts that interrupt during user interaction. Defer their loading or load them via next/script with strategy="lazyOnload".
• Layout thrashing inside scroll handlers. Use requestAnimationFrame and IntersectionObserver instead of measuring layout on every scroll event.
• Synchronous local storage reads during input handling. Move them off the critical path with useDeferredValue or just don't do them.

To measure INP in real users, not just lab conditions, use a Real User Monitoring tool. The Chrome User Experience Report (CrUX) covers the largest sites; for smaller sites, a script like web-vitals plus Plausible or any analytics backend captures the per-session 75th percentile.

LCP: still 2.5s, but actually enforce it

LCP (Largest Contentful Paint) is unchanged: under 2.5 seconds on the 75th percentile of mobile sessions to qualify as Good. What changed in 2026 is that Google now ranks sites that consistently fail this threshold more aggressively.

The LCP candidate on most pages is one of:

• The hero image. Make sure it has priority (Next.js) or fetchpriority="high" (any framework), is served as AVIF or WebP, and is correctly sized for the viewport.
• The main headline (a <h1>). If your H1 is the LCP, the win is fonts. Self-host the font, subset to Latin, preload the LCP weight, set font-display: swap.
• A hero video. Almost always the wrong choice for LCP. Replace the poster image with a real <img> and let the video lazy-load behind it.

Three diagnostics that surface real LCP issues:

1. Lighthouse on a throttled mobile profile. Not desktop. Not your laptop on home WiFi.
2. WebPageTest from a real Greek (or wherever your audience is) edge location.
3. PageSpeed Insights with the "Origin Summary" toggled on, which shows the real CrUX data from your last 28 days of traffic.

CLS: still 0.1, mostly a discipline problem

CLS (Cumulative Layout Shift) target is unchanged: < 0.1. Most CLS comes from one of:

• Images without explicit width and height attributes.
• Ads or embeds (YouTube, Twitter) loading after page render.
• Web fonts that swap visibly (FOIT or FOUT).
• Late-loading hero text that pushes everything else down.

Fixes are mechanical, not architectural:

• Set width and height on every <img> and <video>. Use aspect-ratio in CSS for responsive images.
• Reserve space for ads and embeds with a fixed-height container, even when empty.
• Match your font's metrics with the fallback font using size-adjust, ascent-override, etc. Next.js does this for you when using next/font.
• Avoid late-injected hero text. Render it server-side or with skeleton states.

The 2026 ranking weight

Google has been clear that Vitals are a ranking signal but a modest one. Two things changed in 2026:

1. The mobile-first index now weights Vitals more heavily than the desktop one. If your mobile score is poor, your mobile rankings suffer disproportionately.
2. The "page experience" composite that bundles Vitals with HTTPS, mobile-friendliness, and lack of intrusive interstitials now applies a steeper penalty when Vitals are in the Poor band.

In practice: if you are scoring Good across Vitals, you cannot rank on Vitals alone, but you also cannot lose ranking to a worse-content competitor purely because they have a slightly better TTFB. If you are in Needs Improvement or Poor, you are paying a tax on every keyword you try to compete for.

What to fix first

Honest priority list, in order:

1. Audit INP with real-user data. This is the metric most sites are silently failing.
2. Image optimization if you have a hero image LCP candidate.
3. Font setup if your H1 is the LCP and the font swap is visible.
4. CLS audit on the top 5 pages by traffic. Fix the layout shifts.
5. Long-task elimination on the main thread. Profile the busiest pages.

What this looks like with us

SEO engagements include a Vitals baseline in week one and a Vitals report every month. We do not chase Lighthouse scores in isolation; we chase the real-user 75th percentile in CrUX, because that is what Google ranks on.

If you would rather have this measured properly, the $890 site teardown returns your CrUX snapshot, the issues ranked by impact, and a fix list with effort against each one. Book the fixes after and the fee comes off them.