What Core Web Vitals actually mean for your revenue

Your SEO agency has been mentioning Core Web Vitals for two years. Your developer keeps muttering about LCP. Search Console keeps flagging URLs as "Poor". And somewhere in your head, you've filed all of this under "technical thing my team should handle" without ever quite understanding what's at stake.

Here's the translation, in money.

What Google actually changed

In 2021 Google rolled the Page Experience update into core ranking. They stopped pretending page speed was an edge case and started using three specific metrics — Core Web Vitals — as a real-world signal of whether your page is worth showing. They've refined the metrics since (INP replaced FID in March 2024), but the principle hasn't moved: if your page feels broken, Google would rather show somebody else's.

The "core web vitals business impact" question isn't really about rankings, though. Rankings are the cherry. The cake is what slow, janky pages do to conversion rate, and the cake is much bigger.

Every CWV metric maps onto a moment in your customer's day. Source: Pexels

The three metrics, translated for humans

LCP — Largest Contentful Paint: "time to useful"

What it measures: how long until the main content of the page appears. Not when the page starts loading, not when something appears, but when the biggest meaningful element (usually a hero image or headline) finishes rendering.

• Good: under 2.5 seconds
• Needs improvement: 2.5–4.0 seconds
• Poor: over 4.0 seconds

Business analogy: it's the time between a customer pushing your shop door and actually being able to see the products. Two seconds is fine. Six seconds, with the door half-stuck, they're walking to the next shop on the street.

INP — Interaction to Next Paint: "time to responsive"

What it measures: when a user clicks, taps or types, how long until something visibly happens. This replaced First Input Delay in 2024 because INP measures the worst interaction on a page, not just the first one. A page that loads fast but jankily handles every subsequent click now gets correctly flagged.

• Good: under 200 milliseconds
• Needs improvement: 200–500ms
• Poor: over 500ms

Business analogy: a sales assistant who takes half a second to look up when you say hello, versus one who stares blankly for three seconds before responding. The second one is technically working. They are not selling anything.

CLS — Cumulative Layout Shift: "visual stability"

What it measures: how much the page jumps around as it loads. The classic example: you go to click the "Buy" button, an ad loads above it, everything shifts down, and you click "Subscribe to newsletter" instead. CLS catches that.

• Good: under 0.1
• Needs improvement: 0.1–0.25
• Poor: over 0.25

Business analogy: a shop where the shelves keep rearranging themselves. You eventually buy nothing because you can't trust where anything is.

The numbers always lead somewhere — usually to revenue. Source: Pexels

The revenue link — what the data actually shows

This is where founders start paying attention, because there's no longer a "we should probably improve speed" debate. The numbers are public and they're brutal.

Vodafone rebuilt their UK landing pages with a hard focus on LCP. An 8% improvement in LCP correlated with a 31% increase in sales and a 15% lift in lead-to-visit ratio. They published the case study with Google in 2021. It's still the cleanest causal story in the public domain.

Deloitte's Milliseconds Make Millions study (2020), commissioned by Google, analysed mobile site data for 37 retail, travel, luxury and lead-gen brands. The headline finding: a 0.1-second improvement in mobile site speed produced an 8.4% conversion rate lift in retail and a 10.1% lift in travel. Average order value rose too — 9.2% in retail. Bounce rates dropped 5–9% across categories.

BBC internally tracked that they lost an additional 10% of users for every additional second their site took to load. Not 10% across the board — 10% per additional second, cumulatively.

Pinterest rebuilt their mobile site for performance and reported a 40% reduction in perceived wait times, a 15% rise in SEO traffic and a 15% rise in conversion to sign-up.

Walmart found that for every one-second improvement in page load time, conversions increased by 2%.

Amazon famously calculated that every 100ms of latency cost them 1% in sales. That's a publicly cited figure from 2006 and almost certainly understates the relationship now.

The pattern across every credible study is the same: speed isn't a vanity metric. It maps directly to behaviour, and behaviour maps directly to revenue. A site with a 5-second LCP and 600ms INP isn't just "slow" — it's leaving a measurable double-digit percentage of its potential revenue on the floor.

How to check your own Core Web Vitals

Three tools, in increasing order of usefulness.

PageSpeed Insights (pagespeed.web.dev) gives you both lab data (a simulated test) and field data from real Chrome users — the actual numbers Google uses for ranking. Always pay more attention to the field data. Lab tests are useful for debugging; field data is the truth.

Google Search Console → "Core Web Vitals" report. Shows you, across your entire site, which URL groups are good, need improvement or are poor. Mobile and desktop are tracked separately. If you're a non-technical founder, start here.

Chrome DevTools → "Performance" tab → record a real page load. This is where developers actually find what's broken. You'll see exactly which images, scripts and renders are blowing your LCP budget.

If you do nothing else after reading this, go to Search Console right now and look at your Core Web Vitals report. Five minutes. If the bars are mostly red or orange, you have a revenue problem with a known size.

🎬 Watch: Analytics in motion

The same patterns show up across industries — fix the metrics, the revenue follows.

The fixes that move the needle

LCP — the three big wins

Image optimisation. Nine times out of ten the LCP element is the hero image. Compress it. Serve WebP or AVIF. Set explicit width and height. Use fetchpriority="high" on the hero image so the browser knows it's the priority. Don't lazy-load the LCP image (a classic own-goal).

Server response time. If TTFB is over 600ms, no amount of frontend optimisation will save you. Move to a better host. Cache pages so the server doesn't render them on every request.

Priority hints and preloading. Preload the LCP image. Preload critical fonts. Tell the browser, explicitly, what matters first. On Next.js this is built into the <Image priority> prop; on WordPress it's a one-line filter or a plugin like Perfmatters.

A typical LCP fix on a mid-market e-commerce site moves the metric from ~4.8s to ~1.8s. That's the difference between "Poor" and "Good" in Google's eyes, and based on the Deloitte data, you're looking at roughly a 15–20% conversion uplift.

INP — main thread work and JavaScript discipline

INP is what trips up modern, JavaScript-heavy sites. Even a site with fast LCP can have terrible INP if every click triggers 800ms of React work.

Reduce main thread work. Lighthouse's "Reduce JavaScript execution time" and "Minimize main-thread work" warnings are direct INP fixes. Code-split heavy components. Lazy-load below-the-fold widgets. Audit third-party scripts mercilessly.

Defer non-critical JavaScript. Cookie banners, chat widgets, analytics, A/B testing tools — load them on interaction or after page idle, not in the head.

Avoid long tasks. Any task over 50ms blocks input. Break work into smaller chunks. Use requestIdleCallback for non-urgent work.

On a typical SaaS marketing site running Google Tag Manager, HubSpot, Drift and three analytics tools, deferring those four scripts to interaction will cut INP from ~400ms to ~120ms. That's the difference between Google calling your interactivity "Poor" and "Good".

CLS — reserve the space

Almost every CLS problem is a missing dimension somewhere.

Images. Always set width and height attributes (or aspect-ratio in CSS). The browser reserves the space, the image fills it, nothing shifts.

Ads and embeds. Reserve a min-height container for any third-party embed. Don't let an iframe push your CTA down the page after the user has already started reading.

Fonts. Use font-display: swap carefully, and use size-adjust to match the fallback font's metrics to the web font's. Or use font-display: optional and accept the fallback for slow connections. CLS spikes from fonts are real and almost always fixable.

CLS is the easiest of the three to get into the green. Most sites move from a poor 0.3+ to a good <0.05 in a single afternoon of focused work.

Treating CWV as a gate, not a goal. Source: Pexels

Why Nexus treats Core Web Vitals as non-negotiable

We write performance budgets into every project brief. Mobile LCP under 2.0s, INP under 150ms, CLS under 0.05. Initial JavaScript under 150KB gzipped. CSS under 25KB. These aren't aspirations, they're acceptance criteria — if the build doesn't meet them, we don't ship.

The reason isn't aesthetic. It's that we've worked with too many clients who treat performance as "nice to have, fix it later", and "later" never comes. Then their PPC campaigns underperform, their SEO stagnates, and they spend three months and £30k diagnosing a problem they could have prevented by getting the basics right from day one.

Performance is cheaper at build time than it is in retrofit. Always.

Book a free performance review

We'll pull your real Core Web Vitals field data from Chrome User Experience Report, identify the three changes with the biggest expected revenue impact, and put a number on each. The review is free, takes us about an hour, and you get a written summary either way. Book your review.