Core Web Vitals and page speed: what's worth fixing, and what's diminishing returns

Core Web Vitals have been part of the SEO conversation for a few years now, and most organisations have absorbed the headline message: page speed matters, Google measures it, fix your score. What’s less well understood is which fixes actually move the needle and which ones are effort spent chasing a number that’s already good enough.

Here’s where the current thresholds sit, and where we’d point your time.

The three metrics, and what “good” means

Google’s Core Web Vitals measure three things, each assessed at the 75th percentile of real visits to your site, tracked separately for mobile and desktop:

Largest Contentful Paint (LCP) measures loading performance — specifically, how long it takes for the largest visible piece of content (usually a hero image or headline) to render. Good: 2.5 seconds or less.

Interaction to Next Paint (INP) measures responsiveness — how long the page takes to visibly respond after a user clicks, taps or types. Good: 200 milliseconds or less. INP replaced an older metric, First Input Delay, because FID only measured the delay before a response started, not how long the response itself took to actually show up on screen.

Cumulative Layout Shift (CLS) measures visual stability — whether content jumps around as a page loads (the classic case: you go to tap a button and an ad loads above it, and you tap the wrong thing). Good: 0.1 or less.

Google has said stable Core Web Vitals metrics won’t change more than once a year, so this isn’t a moving target month to month — but it is worth periodically checking you’re still being measured on the current definitions rather than an old one.

Where the effort is genuinely worth it

Getting LCP under control usually has the biggest real-world payoff, because it’s the metric most directly tied to how fast a page feels, and it’s the one where the easy wins are genuinely easy: compressing and correctly sizing images, using modern formats like WebP or AVIF, preloading the hero image or font instead of letting the browser discover it late, and cutting render-blocking CSS and JavaScript that delays the largest element from appearing. If your LCP is sitting well above 2.5 seconds, this is where to start — it’s usually the highest-leverage fix available.

Fixing genuinely janky interactions matters for INP — a search box that lags before showing results, a menu that takes half a second to open, a checkout step that freezes the page while it validates a field. These aren’t abstract scoring problems; they’re the same thing a frustrated user would complain about if you watched them use the site. Long JavaScript tasks that block the main thread are almost always the cause, and breaking them up (or moving work off the main thread) is worth the engineering time.

CLS problems are usually cheap to fix and worth fixing regardless of the score, because they’re also just bad UX — reserving space for images and ads before they load, and avoiding injecting content above what a user is currently reading, are both small, low-risk changes with an immediate, visible improvement.

Where you’re likely chasing diminishing returns

Going from “good” to “perfect.” If your LCP is already at 1.8 seconds, squeezing it to 1.2 seconds is unlikely to move rankings or conversion meaningfully — you’ve already cleared the threshold Google actually scores against. The gap between “good” and “excellent” on a metric that’s already passing is usually the least valuable hour of optimisation work available to you, and it’s exactly the hour a lot of technical audits recommend first, because it’s the easiest number to keep improving on a report.

Micro-optimising a page that gets almost no traffic. Core Web Vitals are assessed per page (and rolled up for ranking purposes at a broader site or template level), so the return on fixing a rarely-visited page is close to zero. Prioritise your homepage, top landing pages, and your highest-traffic templates — a product page template used across thousands of SKUs is worth far more attention than any single page.

Treating the score as the goal rather than the symptom. A common failure mode is a team spending weeks getting a Lighthouse lab score into the green while real-world visitors — measured by actual field data — are still having a slow, janky experience because the lab test doesn’t reflect real network conditions, real devices, or real third-party scripts (chat widgets, ad tech, analytics) loading on top of the page. Optimise against real user data (Chrome UX Report / your own analytics), not just a synthetic test score.

Assuming Core Web Vitals alone will fix a ranking problem. They’re one of many ranking signals, not a silver bullet. A technically fast site with thin or unhelpful content won’t outrank a slightly slower site with genuinely better answers to what the searcher wants. Speed is a threshold to clear, not a lever to keep pulling past the point it’s already cleared.

A sensible order of operations

1. Check your real-world (field) data first — Google Search Console’s Core Web Vitals report or Chrome UX Report — not just a single lab test, which can mislead.
2. Fix any page or template failing LCP, INP or CLS outright before optimising anything already passing.
3. Prioritise by traffic: your homepage and highest-traffic templates first, low-traffic pages last.
4. Address genuinely janky interactions (slow search, laggy menus, blocking scripts) even where the INP number is technically fine — a bad interaction is a bad interaction regardless of the millisecond count.
5. Once everything’s comfortably in the “good” range on real traffic, redirect the budget elsewhere — content, accessibility, conversion work — rather than continuing to shave milliseconds off an already-passing score.

The takeaway

Core Web Vitals are a genuinely useful, evidence-based way to catch real problems — sites that are slow, janky or visually unstable in ways that cost both users and rankings. But “good” is a threshold, not a leaderboard. The value curve is steep at the start and flattens fast once you’re passing; know where you are on that curve before deciding where to spend the next hour of development time.

If you’d like a Core Web Vitals audit of your site — with real field data, not just a lab score — get in touch.