Core Web Vitals and conversion: what the case studies prove, and what they don't

Core Web Vitals are Google's metrics for real-user page experience. There are three:

• LCP (largest contentful paint) covers loading: how long the main content takes to appear.
• INP (interaction to next paint) covers responsiveness: how quickly the page reacts when someone taps or clicks.
• CLS (cumulative layout shift) covers visual stability: whether the page jumps around while it loads.

A page passes when the 75th percentile of real-user (field) data is in the "good" band for all three metrics¹. In plain English: three out of four visits need to be good, not just your developer's laptop on office wifi.

Google defines a "good" band for each metric. People search for the "web vitals thresholds LCP INP CLS" because they want one number per metric, and Google explains how those bands were set in its web.dev article on defining the thresholds². Use the current figures from Google's own pages and PageSpeed Insights rather than from a blog post, including this one. The bands are Google's definition of good page experience. They are not a promise of sales.

One more limit. Passing the assessment is not the same as winning in search, and it is not the same as winning at checkout.

Google's web.dev site publishes a collection of case studies on the business impact of Core Web Vitals³. Two of the best known are worth reading closely.

Vodafone. The web.dev case study describes an A/B test on one Vodafone Italy landing page, with traffic split evenly between an optimised version and the original. The optimised version had a better LCP and more sales⁴. One site, one page, one change set.

Rakuten 24. The web.dev case study describes a month-long A/B test on one Rakuten 24 landing page, where the version optimised for Core Web Vitals had a higher conversion rate⁵. It also reports correlations between good field metrics and conversion, which is a different kind of evidence from the test⁵. Again: one site.

What these studies do support:

• Speed work is worth considering when your pages are poor on real-user data.
• A properly run A/B test can connect a speed change to sales.
• Large, well-resourced sites have done this and reported results.

That is a fair case for taking the question seriously. It is not a forecast.

Possibly. Probably, if your pages are slow for real users. By how much, nobody can say from outside your shop. The case studies are one answer to "can it matter?", not to "how much will it matter here?".

Be careful with the word "conversion". We mean conversion rate as orders divided by sessions, and a case study may use a different definition. Check which one before comparing.

Because the result depends on things the headline leaves out.

• Starting point. A site that moves from very slow to acceptable has more room to gain than one that is already fine.
• Audience and devices. Mobile share, network quality and shopping intent differ between businesses.
• Product and price. A considered purchase tolerates a slower page differently from an impulse buy.
• What else changed. A speed project often ships with design and code changes at the same time.
• Who publishes. A published case study is a result someone chose to share. Google's collection invites businesses to submit their own results³. You do not see the projects that were never written up.
• Correlation versus test. Field-data correlations show that fast pages and good conversion tend to go together. They do not show that speed caused the conversion. Fast sites may simply be better built in other ways too.

Example (illustrative): Imagine a shop whose pages already load well for most visitors. A team spends a quarter on speed because a glowing write-up promised a big lift. The score improves. Orders barely move. Nothing was wrong with the test or the team. The starting point was just different.

Our view: use a case study to decide whether speed is worth a test. Do not use it to size the prize in a business case.

Start with your own field data. PageSpeed Insights reports real-user results where Google has enough data for your pages¹. Check the pages that carry your revenue: the product page, the basket and checkout, not just the homepage.

Then work through it in order:

1. Find the weak pages and the weak metric. Fixing a metric that already passes is wasted effort.
2. Make one change set at a time. If you change speed, design and copy together, you cannot tell which did what.
3. Split traffic if volume allows. An A/B test with a clear primary metric (orders per session, or revenue per session) is the cleanest route.
4. If you can't split traffic, compare carefully. A before-and-after comparison is weaker. Promotions, seasonality and ad changes all move orders. Write down what else changed.
5. Judge on orders and margin, not on the score. A better score that doesn't move orders is still a better score. It just isn't a conversion result.

If speed work needs development time, count that cost against the plausible gain before you start. A test is cheap compared with a quarter of engineering on a guess.

Speed also sits next to search. The same fixes may help your organic visibility, but that is a separate question with its own evidence. If you want help with either side, see our work as an ecommerce CRO agency and as an ecommerce SEO agency.