Core Web Vitals occupy a strange place in SEO. They are the most measurable thing on the list, which makes them feel like the most important thing on the list. They are not. But they are also not nothing, and the balance has shifted since they were introduced.
The three metrics as they stand
- Largest Contentful Paint (LCP) — how long until the main thing on screen has rendered. Aim for under 2.5 seconds. This is the one that correlates most closely with whether a page feels slow.
- Interaction to Next Paint (INP) — how quickly the page responds when someone taps or clicks. Aim for under 200 milliseconds. This replaced First Input Delay, and it is much harder to pass, because it measures every interaction rather than only the first.
- Cumulative Layout Shift (CLS) — how much the page moves around while loading. Aim for under 0.1. Usually the cheapest of the three to fix.
Why INP caught so many sites out
The switch from First Input Delay to INP is the biggest change in this area for years, and it is worth understanding why it stung.
FID measured one thing: the delay before the browser could begin handling your first interaction. It was a forgiving metric. A page could load its heavy JavaScript, sit idle for a moment while you read the headline, take your first click quickly, and pass — then be sluggish for the entire rest of the visit without that ever being recorded.
INP measures every interaction and reports near the worst of them. Opening a menu, expanding an accordion, filtering a product list, closing a cookie banner — all of it counts, and all of it happens at the point when the page is busiest. Sites that passed FID comfortably for years found themselves failing without having changed a line of code.
The practical consequence: LCP is a loading problem, and INP is an architecture problem. The first can usually be fixed with compression and caching. The second often means removing something that somebody in the business asked for.
How much do they actually affect rankings?
Less than the amount of attention they get. Google has been consistent that page experience is a tiebreaker rather than a primary signal: given two pages that answer a query equally well, the faster one has an advantage. Given a fast page with poor content and a slow page with excellent content, the slow one still wins.
Where they matter more is conversion. The commercial case for fixing LCP is usually stronger than the ranking case, and it is the one we lead with when we recommend the work.
Field data is the only data that counts
This is the mistake we correct most often. A Lighthouse score run on your laptop is a lab test with assumed conditions. What Google uses is field data from the Chrome User Experience Report: real visitors, real devices, real networks, assessed at the 75th percentile over 28 days.
That 75th percentile is worth sitting with for a second. It means a quarter of your visitors can have a worse experience than the number you are being graded on. If your audience skews towards older phones or weaker connections, your real-world figure will be worse than anything you can reproduce at your desk.
Two further consequences. A lab score of 100 means little if your actual visitors are on mid-range phones over patchy mobile data. And fixes take up to 28 days to show fully, so do not judge a change after three days and revert it.
Use the Core Web Vitals report in Search Console as the source of truth, and Lighthouse only to diagnose why a URL group is failing.
What usually fixes each one
In our experience the same handful of causes account for most failures.
- LCP is nearly always an oversized hero image, a slow server response, or a font or script blocking the render. Compress and correctly size the hero, preload it, and get the server response under about 600ms with caching.
- INP is nearly always JavaScript. Third-party tags — chat widgets, heat mapping, multiple analytics tools, consent managers — are the usual offenders. Audit what is loading and remove what nobody looks at.
- CLS is nearly always images or ads without reserved space, or a web font swapping in at a different size. Set width and height on images, reserve ad slots, and use
font-display: optionalor a well-matched fallback.
The tag audit nobody wants to run
If a site is failing INP, the fix is almost never clever. It is opening the tag manager and asking, of each script, who looks at this and when did they last look.
The pattern repeats: a heat-mapping tool installed for a redesign three years ago, two analytics platforms because nobody switched the old one off, a chat widget nobody staffs after five o’clock, a personalisation script for a campaign that ended. Each was defensible on its own. Together they are the reason the page takes half a second to respond to a tap.
This is an uncomfortable conversation rather than a technical one, which is exactly why it keeps not happening. It is also, on most sites, the single largest performance win available.
How much budget they deserve
Our rule of thumb: get out of the red, then stop. Moving from failing to passing is worth doing. Moving from a good score to a slightly better one is almost always worth less than spending the same time on content or links.
The exception is a large e-commerce site, where a fraction of a second on LCP has a measurable revenue effect independent of any ranking change. There, the performance work justifies itself without SEO entering into it.
If you are building something new, most of this is cheaper to get right before launch than after — the relevant items are in our technical SEO checklist for new sites.
Performance sits inside our on-page SEO service, and the free audit we run covers your current field data. Request one here.