Are Core Web Vitals Still Worth Chasing?
Yes for your visitors, weakly for your rankings. LCP and INP cost you enquiries whether or not search notices, CLS is an afternoon of work, and the lab score stops mattering the moment field data passes.
On This Page
A developer sends over a screenshot of a green performance score, three digits in a circle, and everyone agrees the site is now fast. Six weeks later somebody asks why the rankings have not moved. The honest answer is that they were never going to move on the strength of that screenshot, because the number was produced by a single simulated load on throttled hardware, and the people who actually visit the site were nowhere in the measurement.
So here is the answer before the argument. Core Web Vitals are worth fixing for what they do to enquiries, and only weakly worth chasing for what they do to rankings. Two of the three metrics cost you money independently of any search engine. The third is cheap manners. And the search benefit, when it arrives, arrives as a tiebreaker rather than as a promotion.
Most Core Web Vitals SEO arguments go wrong because "ranking factor" gets treated as a switch that is either on or off. It is neither. A signal can be real, documented, and genuinely used, while still being the ninth thing that decides which of two pages goes above the other. Knowing which kind of signal you are dealing with is what decides how much of your quarter it deserves.
A ranking factor and a tiebreaker are not the same thing
Search documentation is unusually candid on this point. Page experience signals exist, they are described publicly, and the same documentation says the page that answers the question better will normally still win. Read plainly, that means speed is not a route around being the wrong answer.
The model we hold in our heads: relevance picks the shortlist, and experience can reorder it. If your page is not on the shortlist, no quantity of saved milliseconds puts it there. If it is on the shortlist alongside four near-identical competitors, being the one that does not stutter and jump while it loads is a real advantage, even if it is a modest one.
The honest limitation: nobody outside the ranking team can tell you the weight, and anyone who quotes you a figure for it is inventing it. What you can do is identify which of your pages sit in that crowded, evenly-matched position, and treat those as the ones where a tiebreaker is worth owning. The same reasoning applies to schema markup, where some types earn a visible result and the rest are decoration. Both are real. Neither is a substitute for having something worth ranking.
LCP: how long until the page looks like it arrived
Largest Contentful Paint marks the moment the largest image or text block inside the first screen finishes rendering. Not when the server responded. Not when the spinner stopped spinning. When the thing the visitor came for is on screen at a readable size. Good is 2.5 seconds or less, measured at the seventy-fifth percentile of real loads.
What actually moves it
Four things, roughly in the order they matter: how long the server takes to send the first byte, whether the resource that paints the largest element is discovered early or late, whether something render-blocking sits in front of it, and how large the file is. Most teams jump straight to the fourth. The second is where the expensive surprises live. A hero image inserted by JavaScript after hydration cannot be prioritised by a browser that never saw it in the HTML, and no amount of compression rescues a request that started two seconds late.
This is why LCP belongs to the people building the page rather than to a plugin bolted on afterwards. A website build that puts the hero in the markup, gives it explicit dimensions and serves it in a modern format has done most of this work before anybody opens a performance tab. Retrofitting it means unpicking whatever decision put the image behind a script in the first place, which is usually a component boundary somebody was fond of.
INP: the metric that measures your JavaScript honestly
Interaction to Next Paint replaced First Input Delay, and it is far less forgiving. FID timed how long the browser took to begin handling the first interaction of a visit. INP watches interactions across the whole visit and reports on the slow ones, measuring from the tap to the frame that finally shows a response. Good is 200 milliseconds or less.
The reason INP embarrasses sites that scored well under the old metric is simple. FID could be satisfied by a page that started responding promptly and then took another second and a half to do anything a human could see. INP counts that second and a half. It is the closest thing the web has to a measurement of whether an interface feels alive.
What a poor INP feels like
- A menu that opens a beat after the tap, so people tap again and close it.
- A filter on a product listing that appears to do nothing, so the visitor presses it repeatedly and ends up with four filters they never wanted.
- A form field that swallows the first character typed into it.
- An accordion that expands after the thumb has already moved on, pushing the next question under the finger.
None of that reads as "slow site" to the person experiencing it. It reads as "broken site", which is considerably worse. A slow site gets patience. A broken one gets the back button and a quiet decision never to return.
CLS: the cheapest one to fix and the rudest one to leave
Cumulative Layout Shift measures how much painted content moves without the user asking it to. Good is 0.1 or less. It is the only one of the three you can often fix in an afternoon, and the only one where the remedy is nearly always the same sentence: reserve the space before the thing arrives.
Images and video need explicit width and height, or an aspect ratio, so the browser can hold the gap open. Advertising slots, consent banners and notification bars need a reserved box rather than an insertion into live layout. Web fonts need a metric-compatible fallback so the swap does not reflow three paragraphs under somebody who has already started reading. That is most of CLS, honestly.
The concession: there is one CLS case you may not be able to win. If your revenue depends on advertising slots whose creative arrives at variable sizes, some shift is contractual rather than technical, and the honest response is to reserve the largest plausible box and accept the whitespace. Everyone who has argued that trade with a commercial team knows how it goes. Reserve the space anyway, and lose the argument in writing so it can be revisited when the ad contract is renegotiated.
Field CLS keeps counting while the visitor scrolls and interacts, so lazy-loaded sections, sticky bars and late-injected banners all contribute to a score your lab test never saw. Scroll one of your own pages slowly, on a real phone, on a real connection, before concluding that CLS is fine.
The three metrics, side by side
| Metric | What it measures | Good, at the seventy-fifth percentile | Usual cause of a poor score |
|---|---|---|---|
| LCP | When the largest element in the first screen finishes rendering | 2.5 seconds or less | Slow first byte, a late-discovered hero image, render-blocking CSS |
| INP | How quickly the page paints a response to a tap, click or keypress | 200 milliseconds or less | Long JavaScript tasks holding the main thread |
| CLS | How much painted content moves without the user asking | 0.1 or less | Unsized media, injected banners and bars, font swaps |
Notice what is missing from that table: a column for how much each one helps you rank. We left it out because we cannot fill it honestly, and neither can the person who sold you the audit.
Lab scores are a rehearsal, field data is the performance
A lab tool loads the page once, on simulated hardware, over a throttled connection, from wherever the tool happens to be running. That is a diagnostic. It tells you what is heavy, what is blocking and what arrived in the wrong order, which is genuinely useful when you are deciding what to change.
Field data is different in kind, not in degree. It comes from real visits, on the devices and networks your audience actually owns, aggregated over a rolling twenty-eight-day window. It is what search systems consult, and it is the only number that includes the person on a four-year-old Android handset on a train going through a tunnel. When the two disagree, the field is right and your test rig is wrong.
The lag you have to plan for
Because the window rolls, a fix deployed today does not reach a fully refreshed score for about a month. Teams who do not know this ship a correct fix, check the report a week later, see the old number and conclude it failed. Then they revert it. Our parent company has written about that pattern of impatience more broadly in what ninety days can honestly show, and it applies here almost word for word.
So a performance sprint should end with a written expectation: which metric, on which template, expected to move by which date. If nobody in the room can state that sentence, the work is not finished. It is merely deployed.
A performance report with ninety findings and no order of attack is a document nobody will act on. Insist that every finding carries a severity, a priority and a named fix, which is exactly the shape a reporting tool such as Prooflin is built to produce. The same standard applies to any SEO audit you pay for: findings without priorities are a list, not advice.
Where Core Web Vitals SEO effort actually pays
Here is the part that decides whether any of this deserves a quarter of somebody’s attention. Two of the three metrics cost you money with no help from a search engine at all, and those two are LCP and INP.
A visitor waiting on a hero image is a visitor deciding whether to keep waiting. A visitor whose tap does nothing is forming a view about whether this company can be trusted with a project. Those are conversion problems that happen to have been given search-flavoured names, and framing them that way changes who signs off the work.
Which is why we file LCP and INP work under conversion optimisation as readily as under technical SEO. The budget conversation gets much easier when the metric is tied to enquiries rather than to a position on a chart nobody in the room controls.
- Find the pages that matter. Rank templates by the enquiries or revenue that pass through them. Fix three templates, not thirty URLs.
- Read the field data first. Start from what real visitors experienced, then open a lab tool to explain it. The reverse order produces a long list of things that were never wrong.
- Fix the largest element before anything else. Hero in the HTML, sized, modern format, correct priority hint. That single change moves LCP further than every minification setting combined.
- Cut the JavaScript that runs before interaction. Audit third-party tags without sentiment. A tag manager container is a queue of other people’s scripts contending for the same main thread your buttons need.
- Reserve space for everything that arrives late. Media dimensions, banner slots, consent bars, font fallbacks. CLS is a habit rather than a task.
- Write down when you expect the field number to move. Then look on that date, and not before it.
One more thing worth doing while you are in there: check what else is competing for the same engineering hours. In most cases internal linking returns more, sooner, for a fraction of the effort, and it is the piece of work nobody ever schedules because it does not photograph well.
A page is only as fast as the last thing somebody was allowed to add to it. Performance is a permissions problem before it is an engineering one.
When we would leave the scores alone
There is a version of this work that is theatre, and naming it is the only way to refuse it politely.
If your pages already pass on field data, moving a lab score from the high eighties into the high nineties buys nothing at all. The thresholds are pass or fail. There is no bonus tier for finishing early. Teams spend weeks on that final stretch because the number is visible, improvable and satisfying, while the work that would actually change the quarter is none of those three things.
If the real problem is that nobody finds the page at all, performance is the wrong project entirely. A page that answers the query instead of circling it will do more for you than a second shaved off the load, every time, and it is cheaper to produce than most people assume.
And if enquiries are flat on a site that already loads quickly, stop looking at the timings. Look at what you are asking people to do. Very often the offer is the campaign, and no quantity of milliseconds repairs a proposition nobody wanted. The form deserves the same scrutiny, since a form is a triage instrument long before it is a lead capture.
So, the rule. Fix CLS because it is cheap and leaving it is discourteous. Fix LCP and INP because they cost you enquiries whether or not search ever notices. Ignore the lab score the moment field data passes, and spend the recovered time on content and links instead. If somebody has handed you a report and you want a second reading on which findings are real, send us the templates that matter and we will tell you which three are worth a sprint.
Common questions.
Are Core Web Vitals a ranking factor?
Yes, but a light one. Page experience signals are documented as part of how results get ordered, while the same documentation states that the page answering the question better will usually still win. In practice they behave like a tiebreaker between pages of comparable relevance rather than a way to outrank genuinely better content. Fix them for visitors first, and treat any search movement as a bonus.
What counts as a good LCP score?
A Largest Contentful Paint of 2.5 seconds or less, measured at the seventy-fifth percentile of real page loads, is treated as good, and above four seconds is poor. The measurement marks when the largest image or text block in the first screen finishes rendering, so it reflects the moment the page looks like it has arrived rather than the moment the server replied.
Why did our INP get worse when our old FID score was fine?
Because the two metrics measure different things. First Input Delay timed only how long the browser took to begin handling the first interaction, so a page could start responding promptly and then take a long time to show anything. Interaction to Next Paint measures the full gap, across interactions throughout the visit, and reports the slow ones. Sites carrying heavy JavaScript almost always look worse under it.
How long after a fix do Core Web Vitals scores update?
Field data is aggregated over a rolling twenty-eight-day window, so a change deployed today reaches a fully refreshed score roughly a month later. Lab tools update immediately, which is why teams often assume a fix failed when the field report still shows the old number a week in. Agree the measurement date before you deploy, and resist reverting a correct change during the wait.
Is a perfect lab performance score worth chasing?
No, not once your field data passes. The thresholds are pass or fail, with no extra credit for a higher number, and a lab tool runs a single simulated load on throttled hardware rather than measuring your actual visitors. Treat it as a diagnostic that explains why a real-world score is poor. Chasing the last few points is visible work that changes nothing for anybody.
Do Core Web Vitals affect conversion rates?
They affect the behaviours that conversion depends on. A slow largest paint gives a visitor time to reconsider, an unresponsive tap reads as a broken site rather than a slow one, and content that jumps causes mis-taps on the wrong control. We would not quote you a figure for the size of that effect, because it varies by audience, device mix and intent. The mechanism itself is not in doubt.
Facing this in your
own business?
Tell us where you’re headed — we’ll map the shortest honest route.