Which Core Web Vitals Actually Matter, and What to Do About Each

There are three Core Web Vitals. If someone is still talking to you about First Input Delay, their information is at least two years stale — INP replaced FID on 12 March 2024, and Chrome stopped supporting FID in its tools that September.

The three that exist, with the thresholds Google actually uses:

Metric	What it covers	Good	Needs improvement	Poor
Largest Contentful Paint (LCP)	Loading	≤ 2.5s	2.5s – 4.0s	> 4.0s
Interaction to Next Paint (INP)	Responsiveness	≤ 200ms	200ms – 500ms	> 500ms
Cumulative Layout Shift (CLS)	Visual stability	≤ 0.1	0.1 – 0.25	> 0.25

Those come from Google's documentation for LCP, INP and CLS. The number that matters is not your average but the 75th percentile of page loads, segmented separately for mobile and desktop, and a page passes only if all three are good there. One visitor in four can have a worse time than your reported figure and you still pass — so if your mobile 75th percentile is poor, far more than a quarter of people are suffering.

Is this actually a ranking factor, or is it being sold to me?

Both, and the size of it is worth being precise about.

Google's position is that there is no single page experience score: "There is no single signal. Our core ranking systems look at a variety of signals that align with overall page experience." Core Web Vitals are the one page experience aspect Google names as used by ranking systems. The rest of what gets bundled into "page experience" in agency decks — HTTPS, mobile friendliness, no intrusive interstitials — Google says "don't directly help your website rank higher in search results."

Two more lines from the same page are worth pinning above any performance budget. Search "always seeks to show the most relevant content, even if the page experience is sub-par", and "trying to get a perfect score just for SEO reasons may not be the best use of your time."

So a fast page with weak content does not rank. Core Web Vitals are a tie-breaker between pages that are otherwise comparably helpful — a real thing to win, but a small one. If you are on page three for a query, performance is not why.

The honest reason to fix them is harder to attribute and therefore rarely in a proposal: people abandon slow pages and misclick shifting ones. That shows up in conversion rate, not rankings.

For calibration: the HTTP Archive's 2024 Web Almanac found 43% of sites had good Core Web Vitals on mobile. Failing is normal.

What is LCP really measuring, and why does it fail?

LCP is the moment the largest piece of content in the viewport finishes rendering — not "the page loaded", just that the biggest visible thing appeared. Candidates are <img>, <image> inside SVG, <video> poster frames, elements with a CSS url() background, and block-level elements containing text. CSS gradients do not count, which is why a page with a gradient hero reports its headline as the LCP element.

Google's own breakdown is the useful way to think about it. LCP is four consecutive stretches of time, with a recommended share of the total for each:

Sub-part	Target share of LCP
Time to First Byte	~40%
Resource load delay	under 10%
Resource load duration	~40%
Element render delay	under 10%

That table is more diagnostic than any score. If TTFB is 70% of your LCP, no amount of image compression will save you — the problem is the server, the query, or the distance to the user. If resource load delay is large, the browser found out about your hero image late, because it is injected by JavaScript, lazy-loaded, or buried behind a CSS file.

The commonest cause we see is exactly that: a hero image the browser cannot discover in the initial HTML. Lazy-loading it is the classic own goal — a well-meaning loading="lazy" on the one image that defines LCP, which Google says explicitly never to do.

Second commonest is render-blocking CSS and fonts. Text using a web font is not considered rendered during the font block period, so a slow font turns a fast server into a slow LCP.

Why INP is the one that will surprise you

INP measures how long it takes, from a tap or click or key press, for the browser to paint the next frame. It observes only mouse clicks, touchscreen taps and key presses — scrolling, hovering and pinch-zoom are not interactions. The reported value is effectively the worst interaction of the visit, discarding one outlier per 50, taken at the 75th percentile across page loads.

That definition is why INP catches people out: it is not a load metric. A page can have a fast first paint and still lock up for 400ms every time someone opens a dropdown, and INP is the only vital that notices.

Latency splits three ways — input delay (a long task stops your handler from even starting), processing duration (your handler is slow), and presentation delay (the rendering after it is slow). People reflexively optimise the second. The first and third are usually bigger.

The fixes that reliably work, per Google's INP guidance:

• Break up long tasks. Yield to the main thread inside handlers instead of doing everything at once. Google's own phrasing — "yielding indiscriminately is better than not yielding at all" — is unusually permissive for a performance team, and should be taken at face value.
• Update the UI first, defer the rest. Keep only the work needed for the next frame in the event callback. Autosaves, analytics calls and spellchecks go in a later task.
• Reduce DOM size. A large DOM slows every interaction's rendering step, not just first paint. A table rendering 2,000 rows client-side is an INP problem wearing a UX problem's clothes.
• Stop rendering large amounts of HTML in JavaScript. Server-streamed HTML is parsed incrementally; a big innerHTML assignment is not, and the browser will not yield until it finishes. The same instinct avoids layout thrashing — reading a layout-dependent style straight after writing one forces a synchronous layout.

If you are on a modern React framework and INP is bad, the answer is almost never "add more memoisation". Usually too much is hydrating, or a third-party script owns the main thread in exactly the window when people first try to interact.

Is CLS worth bothering with?

Yes — it is the cheapest of the three to fix and the most annoying to users.

CLS is not a time. Each shift scores impact fraction × distance fraction — how much of the viewport moved, multiplied by how far. The reported figure is the worst session window, a window being shifts less than 1 second apart capped at 5 seconds. One bad moment during load decides your score; small wobbles do not accumulate forever.

Google's list of causes: images and videos without declared dimensions, fonts that render at a different size from their fallback, third-party ads and widgets that resize themselves, async resources, and DOM elements injected above existing content. Four fixes cover nearly all of it:

1. Put explicit width and height (or an aspect-ratio) on every image and video, including ones from a CMS.
2. Reserve space for anything that arrives late — ad slots, embeds, consent banners, that "20% off" bar.
3. Match your fallback font's metrics to the web font, or use size-adjust so the swap does not resize the text.
4. Animate with transform, not with properties that trigger layout.

One piece of good news: shifts within 500ms of a tap, click or keypress are excluded as user-initiated, so an accordion that expands when clicked is not penalised. Scrolls, drags and pinch-zoom do not count, which makes lazy-loaded content below the fold a real CLS source that lab tools often miss.

How do I tell a real problem from a lab artefact?

This is the question that saves the most wasted effort.

Lab data — Lighthouse, PageSpeed Insights' diagnostics half, a CI check — is one device, one network, one location, a cold cache and no user. Field data is real people's devices, networks, caches and behaviour, reported as a distribution. Google's guidance is to prioritise field data and use lab data to find the fix. Lab tells you why; field tells you whether. The specific traps:

• INP cannot be measured in the lab in any meaningful way. It depends on when a real user chose to interact. Lighthouse's stand-in is Total Blocking Time, and a page can have good TBT and poor INP.
• Lab and field LCP often pick different elements. Screen size, personalisation, A/B tests and font timing change which element is largest. Lab tools keep looking until full load; field measurement stops at the first interaction or scroll.
• Lab CLS is mostly above-the-fold load shifts. Field CLS also catches shifts from scrolling and lazy-loaded content, which is why it is sometimes much worse than a clean lab run suggested.
• The Lighthouse performance score is not a Core Web Vital. Its weighting is Total Blocking Time 30%, LCP 25%, CLS 25%, FCP 10%, Speed Index 10%. Two of the five are not vitals, and the heaviest input is a metric Google does not use for ranking. A 92 and an 88 are not meaningfully different.
• The default mobile run is a simulation. Lighthouse models a 150ms round trip, 1.6 Mbps down and a 4× CPU slowdown relative to the machine running the test, so the same site scores differently on your laptop and on a busy CI runner.

One caveat about the field data itself, because people treat CrUX as ground truth. CrUX only includes Chrome users with usage statistics reporting on, history sync enabled and no sync passphrase set — Chrome on iOS, Android WebViews and other Chromium browsers such as Edge contribute nothing. The URL must be publicly indexable and clear an undisclosed popularity threshold, and it is aggregated over a rolling 28 days, so a fix you shipped last week stays diluted for a month.

The practical rule: if the field section of Search Console or PageSpeed Insights says a group of URLs is poor, believe it and use lab tools to find out why. If only the lab score is bad while field data is fine, write it down and move on. And if there is no field data at all, its absence proves nothing — you have a traffic problem, not necessarily a performance one.

What not to do

Don't chase 100. The thresholds are pass/fail at the 75th percentile and there is no reward above "good". The last ten points cost more than the first forty and buy nothing a user can feel.

Don't optimise a page nobody lands on. Sort your entry pages by sessions first. A 2% improvement to the page taking 40% of your organic traffic beats rebuilding one that gets eleven visits a month.

Don't delete the thing that makes the page work. Removing the chat widget that produces a third of your enquiries to gain 300ms is not an optimisation, it is a revenue decision made by an engineer. If a script earns its weight, keep it and load it properly.

Don't let it become the whole SEO plan. Fixing vitals on a site with thin content and no reason to be cited will not move rankings. Performance belongs in the technical hygiene column, next to correct canonicals and a sitemap that is not lying.

Don't trust a single run. Treat performance as a distribution, which is what Google's own scoring documentation advises.

If you have one afternoon

In order, and stop when you run out of time:

1. Open Search Console's Core Web Vitals report and note which metric fails on mobile, and for which URL groups. Mobile only, to begin with.
2. For the worst group, run PageSpeed Insights and read the four LCP sub-parts. Fix whichever is over its share.
3. Add explicit dimensions to every image in the templates those URLs use. Usually an hour, and usually fixes CLS outright.
4. List your third-party scripts, find an owner for each, and delete the ones nobody can justify. There is always at least one.
5. Install field measurement, so the next conversation is about users rather than a test runner.

The order is deliberate: it starts with evidence that real users are affected and ends with proof of whether anything you did worked.

All of this is cheaper to get right during a build than to retrofit, and none of it costs extra at build time — server-rendered HTML, images with dimensions, fonts self-hosted and preloaded, third-party scripts on a short leash. That is roughly how we approach web development, and what a build costs is set out in website development pricing in India.

If you have a Search Console report full of red and want someone to say which two lines of it are worth acting on, send it over. Often enough the answer is that one template causes all of it and the fix is an afternoon — and we would rather tell you that than scope a performance retainer.