Core Web Vitals: The Three Numbers That Decide Your SEO

There are three numbers that decide how your website feels to a real person on a mid-range phone with a bad connection.

They also decide how you rank. And the gap between a site that passes them and a site that fails them is the difference between a visitor reading your pricing and a visitor closing the tab.

We check these on essentially every engagement, and the pattern is consistent enough that we can describe the fixes that work.

LCP — Largest Contentful Paint

What it measures: how long until the largest visible element appears.

Good: under 2.5 seconds. Needs work: 2.5–4s. Poor: over 4s.

LCP is the number people feel as "is this site slow?" It is almost always an image, a headline block, or a hero video.

What actually fixes it

Serve the right file. The most common failure is a 2 MB hero image served at full resolution to a phone. We have seen a single unoptimised hero image add 1.8 seconds to LCP on a mid-range Android device over 4G.

The fix is straightforward: WebP or AVIF, sized appropriately for the viewport, with srcset so a phone never downloads a 2400-pixel-wide file. This is not an optimisation, it is basic hygiene.

Preload the LCP image. If you know which image is the largest above the fold, tell the browser before it parses the CSS:

<link rel="preload" as="image" href="/assets/img/hero.webp" fetchpriority="high">

Stop competing with it. Any script, font or stylesheet that renders above the hero delays the hero. A third-party chat widget loaded in the head is a common culprit.

Serve the hero from the edge. This is the part people get wrong. A 200 KB image served from a server two continents away does not arrive 200 KB's worth of time faster. Edge caching is the single biggest LCP improvement available to most sites.

INP — Interaction to Next Paint

What it measures: the delay between a person tapping something and the screen responding.

Good: under 200 ms. Needs work: 200–500 ms. Poor: over 500 ms.

INP replaced First Input Delay as the responsiveness metric because FID only measured the first interaction and ignored everything after it. A site can have a great FID and a terrible INP, which is exactly what happens when a customer has scrolled for a while, opened three tabs and then tries to use a filter.

What actually fixes it

Break up long tasks. This is the core of it. Any JavaScript task running longer than 50 ms can block the main thread and make the interface feel unresponsive. Long tasks come from big bundles, heavy libraries, synchronous data processing and expensive render work.

Do less work on interaction. If a click triggers a re-render of a large list, do the work in chunks or defer it. The interaction should paint something immediately — a pending state, a skeleton — even if the real update takes a moment.

Be careful with third-party scripts. Analytics, chat, tag managers and personalisation tools are the most common cause of bad INP on otherwise fast sites. Load them after interaction, or not at all.

Virtualise long lists. Rendering two thousand DOM nodes on scroll is a jank generator. Rendering the visible thirty is not.

Audit the interactions specifically. A page can have excellent INP on load and terrible INP when a modal opens, because opening a modal is where heavy work tends to be concentrated.

CLS — Cumulative Layout Shift

What it measures: how much the content moves around while the page is loading.

Good: under 0.1. Needs work: 0.1–0.25. Poor: over 0.25.

CLS is the one users notice without being able to name it. The classic case: you are reading, an ad loads above the content you were reading, and your paragraph jumps down the page. You have been moved by something that was not a control.

What actually fixes it

Reserve space for everything. Every image, video, iframe, ad and banner needs dimensions before it loads.

<img src="cover.webp" alt="..." width="1200" height="630" loading="lazy" decoding="async">

Set aspect-ratio on media containers. If the dimensions change for different breakpoints, the CSS property handles it more reliably than the attributes alone.

Do not inject content above existing content. Cookie banners, promotional bars and "we just got a new lead" notifications are the top three causes of CLS on real sites. If you must have them, reserve the space before they arrive.

Be careful with web fonts. A fallback font with different metrics will reflow the text when the real font loads. font-display: swap prevents invisible text, but size-adjust on the fallback or font-display: optional prevents the reflow as well.

Keep ads in sized containers. Ad slots without a reserved height are CLS on every single load.

Why they matter beyond the score

Three reasons, roughly in order of importance.

They are a ranking factor, but not the one people think. Core Web Vitals are part of Google's ranking systems, and they correlate with commercial outcomes strongly enough that site speed shows up in revenue data everywhere. But we would be dishonest if we said "fixing CWV will move your traffic dramatically". It will not do that on its own. It will make the traffic you already have behave better.

They change behaviour. Fast sites get more pages per session, more form completions and lower bounce on the pages where people actually make decisions. The effect compounds with every page you fix.

They are the visible part of a deeper problem. When we audit performance, we usually find the same underlying issues: images shipped at the wrong size, third-party scripts nobody owns, JavaScript doing work that should happen on the server, and a caching strategy that was never designed. Core Web Vitals are the symptom. Fixing them properly means fixing those things.

A sensible order of work

If a site is failing all three, this is roughly the order that pays back fastest.

1. Images. Right format, right size, explicit dimensions. Usually the biggest single win, and the least risky.

1. Caching and edge delivery. HTML, CSS, JS and images with sensible cache headers. Usually the second biggest.

1. Third-party scripts. Audit every tag, remove what does nothing, defer the rest.

1. JavaScript weight. Ship less, split more, move work server-side.

1. Fonts. Subset, preload the critical face, match fallback metrics.

1. Reserving space. Images, ads and banners. Cheap, and immediately visible.

You can measure all of this in PageSpeed Insights, and the field data in the Chrome UX Report is the number that actually matters — field data is what real users experienced, not what a lab test produced.

Performance is one of the few things in web design where the work is unambiguous and the return is measurable. If your site is slow and you are not sure where to start, ask us for a performance audit — or read about how we build for speed from the start in web development.