Do Core Web Vitals actually affect conversion?

The Core Web Vitals debate is stuck between two positions. On one side, teams that say "Google called it a ranking signal, so everything must turn green." On the other, teams that say "we convert fine already, speed is an excuse." Both produce bad decisions in the field. The useful question is narrower: which metric, at which threshold, for which traffic segment, is costing money?

What follows treats the three metrics threshold by threshold, then ranks where to spend limited engineering hours.

Speed and conversion are related by thresholds, not by a curve

The most common mistake is imagining speed as a continuous gain curve. Generalisations of the "every 100ms is worth X% in conversion" variety come from single case studies, and they rarely transfer to your own site. Behaviour in the field looks more like a staircase: users tolerate waiting up to a certain point, and past that point their behaviour changes abruptly.

A practical way to split it:

• LCP under 2.5s: the page reads as fast. Getting from here to 2.0s does not produce a measurable conversion difference. If you have budget, spend it elsewhere.
• 2.5–4s: the grey zone. You see bounce increases on mobile and on cold users arriving from paid ads, but the effect stays limited on organic and brand traffic.
• Above 4s: this is where the bleeding starts. On paid traffic in particular, the share of users who leave before the page renders climbs noticeably. Since you paid for the click, that is burnt budget.
• Above 6s: a significant share of mobile users never sees the page at all. These users often aren't even recorded cleanly as sessions in analytics, so the loss looks smaller than it is.

That is why the first move is to stop looking at averages and look at percentiles. Your average LCP might be 2.8 seconds, but if the 75th percentile on mobile is 6.4 seconds, a quarter of your traffic is having an experience with no chance of converting. This is exactly why Core Web Vitals are assessed at the 75th percentile.

The most expensive metric may be CLS and INP, not LCP

LCP dominates the conversation because it is easy to measure and looks tidy in a report. But the real damage at the bottom of the funnel comes from the other two.

CLS: the metric that manufactures mis-taps

Layout shift is the only vital that inserts itself between a user's intent and their action. Someone is about to tap "Add to cart" when a late-loading banner pushes the layout down, and their thumb lands somewhere else. The result: wrong page, back button, sometimes an exit.

The fastest way to understand CLS's effect on conversion is to look at behaviour rather than the metric. If rage clicks and fast back-navigations are up on product pages in your session recording or heatmap tool, there is usually a shift problem underneath. In checkout steps especially, a CLS above 0.1 leads to skipped form fields and accidental confirmations.

INP: they pressed the button and nothing happened

Since INP replaced FID it has been a more honest metric: it no longer measures only the first interaction but the worst interaction latency across the session. That matters for commerce and form-heavy sites, because the first tap is usually fast. Problems show up in JavaScript-heavy interactions: selecting a variant, applying a filter, adding to cart.

What does a user do when they tap a button and get no visual feedback for 400ms? They tap again. Depending on your setup, that means a duplicate order or a reset form. On sites above the 200ms INP threshold it is common to see a strong correlation between cart abandonment and device class: on mid-range Android hardware, conversion can fall to half of what the same site achieves on recent iPhones.

Which fixes return the most for the least budget?

When engineering hours are limited, order matters. The list below is sorted by cost-to-impact ratio; the first three are a few days of work on most projects.

1. Discipline the hero image. Convert it to WebP or AVIF, serve it at its real display size, set `fetchpriority="high"` and take it out of lazy loading. On sites with LCP above 5 seconds this alone frequently recovers 1–2 seconds, because the LCP element is usually that image.
2. Take an inventory of third-party scripts. A chat widget, three heatmap tools, two legacy remarketing pixels, an A/B testing tool nobody logs into. Write down when each was added and who uses it today. Delete the unused ones, load the rest after first interaction or with `defer`. This is the single fastest lever on INP.
3. Reserve space. Give images and iframes `width`/`height` or `aspect-ratio`; allocate fixed heights for banners, promo bars and cookie notices. Keeping CLS near zero costs almost nothing but attention.
4. Fix font loading. `font-display: swap`, `preload` for critical fonts, remove unused weights. It moves both LCP and perceived speed.
5. Unblock the main thread. Break up long tasks around interactions like add-to-cart and filtering, and give immediate visual feedback on tap (button state, spinner). Feedback doesn't fix the underlying latency, but it prevents the second tap.
6. Then look at server response time. If TTFB is above 800ms, image optimisation only takes you so far. Caching layers, CDN and database queries come in here — the most expensive item, which is why it's last.

Note what is not on this list: "let's switch themes" or "let's rebuild the site." A rebuild justified by Core Web Vitals is almost always the wrong call. Performance improves as a consequence of architectural decisions, not as a reason for them.

How do you prove the impact?

Measurement is the weakest part of performance work. Your PageSpeed Insights score went from 42 to 78 and revenue didn't move — a very common scenario, because the thing being measured and the thing being earned are not the same.

A more defensible approach:

• Use field data, not lab data. Lighthouse is one simulation; the Chrome UX Report and your own RUM show real users. Decisions get made on field data.
• Replace before-and-after with segment comparison. Within the same period, compare conversion rates for users in the fast and slow percentiles. That isolates seasonality and campaign effects.
• Fix one metric on one page type at a time. Improve LCP on product detail pages first, wait two weeks, then move to checkout. Change everything in the same week and you will never know what worked.
• Tie it to a revenue metric. Look at revenue per session rather than conversion rate alone. Speed improvements sometimes leave conversion rate flat while raising basket size, because users spend the saved time browsing more products.

A ranking effect or a conversion effect?

Core Web Vitals are a ranking signal, but a weak one. They behave like a threshold factor that only engages when content relevance and authority are otherwise equal: bad performance is penalised, excellent performance is not rewarded. The SEO return on the third week spent chasing green is usually close to zero.

Conversion is a different story. Once you cross the threshold there, the effect is immediate and direct: the page opens, the button responds, the form doesn't jump. Which means performance work belongs in the conversion optimisation budget, not the SEO budget. Spending serious money on paid traffic every month and pointing it at a landing page with a 6-second mobile LCP is the most expensive performance mistake available — every lost user there carries a price tag.

Short version: turning every metric green is not a goal. Find out which threshold the worst quarter of your traffic falls below, work out which channel is paying for that quarter, and start there.