Core Web Vitals, and what a slow site actually costs you

Core Web Vitals are three measurements Google takes of real visitors on your site: how quickly the main content appears (LCP), how quickly the page responds to a tap (INP), and how much the layout jumps around while loading (CLS). They are a ranking signal, but the larger effect is commercial — slow pages lose visitors before anyone reads the offer.

Site speed gets discussed as an SEO issue. It is really a revenue issue that happens to also be an SEO issue.

The three numbers

LCP — Largest Contentful Paint. How long until the main thing on the screen appears. Usually your hero image or headline. Target: under 2.5 seconds.

INP — Interaction to Next Paint. How long the page takes to visibly respond when someone taps something. This replaced the older FID metric on 12 March 2024 and is considerably harder to pass. Target: under 200 milliseconds.

CLS — Cumulative Layout Shift. How much the page moves while loading. This is the metric behind tapping a button and hitting an advert because the content jumped. Target: under 0.1.

Metric	Good	Needs work	Poor
LCP	under 2.5s	2.5s to 4s	over 4s
INP	under 200ms	200ms to 500ms	over 500ms
CLS	under 0.1	0.1 to 0.25	over 0.25

Google assesses these at the 75th percentile of real visits — so three out of four visitors must have a good experience, not the average one. This is why a site can look fine in a lab test and still fail.

Why the test device matters more than the score

Most sites are tested on a designer's laptop over office broadband. Your customers are on a three-year-old Android handset on a 4G connection on a commute somewhere.

That gap is not marginal. A mid-range Android has roughly a quarter of the JavaScript processing power of a modern laptop, so a page that feels instant to the person who built it can take eight seconds for the person who was going to buy something.

Two practical implications:

• Use field data — the Chrome User Experience Report, visible in Search Console and PageSpeed Insights — not just lab scores. Field data is what Google actually uses.
• Test on a real mid-range phone on mobile data at least once before launch.

The four fixes that move the numbers most

1. Images

Usually the single largest cause of poor LCP. Serve modern formats (WebP or AVIF), size them for the space they occupy rather than uploading a 4000px photograph, and give every image an explicit width and height so nothing shifts while loading.

import Image from "next/image";

<Image
  src="/img/hero.jpg"
  alt="Description of what the image shows"
  width={1200}
  height={630}
  priority
/>

The priority flag matters: it tells the browser to load the hero image first rather than treating it like everything else.

2. Fonts

Self-host them, subset them to the characters you actually use, and set font-display: swap so text is readable while the font loads. A font that blocks rendering delays LCP directly, and a font that swaps without a matched fallback causes layout shift.

3. Third-party scripts

Every chat widget, heatmap, review embed and tag manager container is someone else's JavaScript running on your critical path — and the main cause of poor INP. Audit what is actually installed. Most sites we look at are running at least one script nobody remembers adding and nobody looks at.

4. Send HTML, not instructions for building HTML

A page that arrives as rendered HTML displays immediately. A page that arrives as an empty container plus a large JavaScript bundle has to download, parse and execute that bundle before anything appears — on a device with a quarter of your laptop's power.

What it is worth

Faster pages convert better, rank better, and cost less to advertise against, because landing page experience feeds into your Google Ads Quality Score and therefore what you pay per click.

It is one of the few changes that improves three numbers at once, which is why we treat it as a marketing investment rather than a technical chore.

Common questions

Do Core Web Vitals really affect rankings? Yes, but as a tiebreaker rather than a primary factor. Between two pages of similar relevance, the faster one wins. A fast page with poor content still loses to a slow page with the right answer.

Is a PageSpeed score of 100 the goal? No. The lab score is a diagnostic. What counts is the field data at the 75th percentile, and chasing the last few lab points usually costs more than it returns.

How often should we check? Monthly in Search Console, and before and after any significant release.

See how we approach this in web development, or talk to us about your current site.