AIDoes site speed affect sales? What the A/B tests measured
Vodafone made its landing page 31% faster in an A/B test and sold 8% more. Which speed studies hold up, and how to price the delay on your own site.

The revenue cost of site speed is the share of sales a website loses while visitors wait for its pages to appear and respond. It is real, and you can measure it. In an A/B test where two versions of a landing page differed only in speed, Vodafone made the main content appear 31% sooner and sold 8% more. Rakuten 24 ran a similar test on its online store and saw revenue per visitor rise 53%.
This piece is for whoever signs off on the website budget: a founder, a head of e-commerce, a marketing lead deciding whether a performance project is worth paying for. It separates the studies that hold up from the numbers that only get repeated, explains why some sites lose more than others, and shows how to put a monthly figure on your own site's delay. For the causes of a slow site and how to fix each one, read why is my website slow.
Does site speed affect sales?
Yes, and the best evidence comes from experiments, not surveys. When the same page is served fast to half the visitors and slower to the other half, the fast half buys more, sends more forms and leaves less often. The gain is largest on pages that start slow, on phones, and at the steps closest to the purchase. Past Google's thresholds for a good experience the gain shrinks, because fewer visitors are left waiting.
What do the controlled tests show?
Three published cases isolate speed from everything else, or come close.
- Vodafone. Vodafone split paid traffic 50/50 between two landing pages that looked and worked the same, each getting about 34,000 visits a day. Version A rendered its critical HTML on the server, moved a widget's rendering off the browser and resized its images. That gave it a 31% better Largest Contentful Paint (LCP), the moment the main content appears, measured on real visits. It produced 8% more sales, a 15% better lead-to-visit rate and an 11% better cart-to-visit rate, according to the case study on web.dev.
- Rakuten 24. The Japanese online store ran an A/B test focused on Core Web Vitals and related metrics. The faster version lifted revenue per visitor by 53.37%, conversion rate by 33.13% and average order value by 15.20%, and cut the exit rate by 35.12% (web.dev).
- redBus. The Indian bus-ticket site worked on Interaction to Next Paint (INP), the time between a tap and the screen's answer, and improved it by 72% on one page. Overall sales rose 7%, web.dev reports. The case study does not describe a split test, so part of that rise could have other causes.
All three are published on web.dev, Google's developer site, and Google has an interest in a faster web. The numbers are still useful because the method is stated: who was tested, what changed and how it was measured.
What about the big studies with millions of sessions?
The most cited one is Milliseconds Make Millions, commissioned by Google and run by Deloitte and 55. It followed 37 European and American brand sites and more than 30 million mobile sessions, with no redesigns during the study. When a site improved four speed metrics by 0.1 seconds on every page of the journey, retail shoppers moved from product page to basket 9.1% more often and spent 9.2% more. Travel sites saw booking rates rise 10%. Lead-generation sites saw 21.6% more visitors reach the form submission page.
Read it as a strong correlation, not a promise. The study watched speed and behavior hour by hour; it did not slow pages down on purpose. And the 0.1 seconds had to be gained on all four metrics at once, on every page of the funnel, which is a bigger project than the headline suggests. One of the four metrics, First Meaningful Paint, has since been retired in favor of LCP.
Which speed statistics should you stop quoting?
The most repeated figure, that every 100 milliseconds cost Amazon 1% of sales, is attributed to a 2006 talk by former Amazon engineer Greg Linden. It has traveled through slides and blog posts for twenty years without a paper you can read to check how it was measured. Treat it as an anecdote from a different web: desktop browsers, slower servers and no smartphones in the sample.
The same goes for any percentage that arrives without a study name, a date and a sample size. If the source cannot say which pages, which metric and which visitors, the number cannot help you size a budget.
Why does speed cost some sites more than others?
Because the loss sits on the visitors who wait. Google's Core Web Vitals draw the line for a good experience at an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less and a Cumulative Layout Shift (CLS) of 0.1 or less, measured at the 75th percentile of real visits, as web.dev documents. The 2025 Web Almanac by HTTP Archive found that 48% of mobile sites pass all three, against 56% on desktop.
Three things decide how much a given site loses:
- Where it starts. A site with a 5-second LCP on phones has many visitors close to leaving. A site at 1.8 seconds has few. The first second you remove is worth more than the last.
- The device mix. Phones on mobile networks wait longest, which is why every study above measured mobile traffic.
- The step of the journey. Delay hurts most where the visitor is about to commit: product page to basket, form to submit, plan to checkout. A slow article costs attention. A slow checkout costs orders.
Does a slow site also lose search traffic?
Some, but less than most owners fear. Google says its core ranking systems reward a good page experience and lists Core Web Vitals as part of it. It also says Search "always seeks to show the most relevant content, even if the page experience is sub-par" (Google Search Central). Speed helps when several pages answer a query equally well; it will not lift a page that answers it worse. So most of the money in speed is in conversion, on visitors you already have.
How do you measure what speed costs your own site?
You can estimate it in an afternoon with data you already have, then confirm it with a test. Four steps.
- Read the field data for the pages that make money. PageSpeed Insights shows the Chrome UX Report for a URL: the LCP, INP and CLS your real visitors got over the last 28 days. Search Console's Core Web Vitals report groups your pages by status. A Lighthouse score is a lab test on one simulated device, not what your customers saw.
- Join speed and conversion in your analytics. Send each visit's LCP and INP to your analytics tool (Google's open-source web-vitals library does it in a few lines) and tag each session as good, needs improvement or poor. Then compare the conversion rate of the three groups, per device.
- Turn the gap into money. Take the sessions in the slow group, multiply by the difference in conversion rate between the fast and slow groups, then by the average order value or the value of a lead. That is the monthly revenue at stake.
- Confirm it with a split test. Slow sessions also come from older phones and weaker connections, and those visitors may buy less for other reasons. So the figure from step 3 is a ceiling, not a forecast. The way to find the real number is Vodafone's: serve a faster version of one page to half the traffic, keep everything else the same, and compare.
What this looks like in practice
Take an online shop with these numbers, invented for the example: 40,000 mobile sessions a month, 30% of them in the poor LCP group, a 1.2% conversion rate in that group against 2.0% in the good group, and an average order of €60.
- Slow sessions: 12,000 a month.
- Conversion gap: 0.8 percentage points, so 96 orders a month.
- Ceiling of revenue at stake: 96 × €60 = €5,760 a month, about €69,000 a year.
If a split test then shows that half of that gap is real, the speed work is worth about €2,900 a month to this shop. That figure, set against the quote for the fix and the cost of keeping the site fast after it, is the decision. On a Next.js site the usual fixes are known and listed in Core Web Vitals on Next.js in 2026.
When is speed not the problem?
When the field data is already green and conversion is still low. A page that passes all three Core Web Vitals at the 75th percentile has few visitors left waiting, and more speed work moves little. The leak is then in the offer, the price, the copy or the form. Speed is one cause of a low conversion rate among several. It is also the easiest one to measure, which makes it tempting to fix first even when it is not the biggest.
Sources
- web.dev: Vodafone, a 31% improvement in LCP increased sales by 8%
- web.dev: How Rakuten 24's investment in Core Web Vitals increased revenue per visitor by 53.37%
- web.dev: How redBus improved INP and increased sales by 7%
- web.dev: Milliseconds make millions (Deloitte and 55 for Google)
- web.dev: Web Vitals
- HTTP Archive Web Almanac 2025: Performance
- Google Search Central: Understanding page experience
Frequently asked questions
There is no single figure that holds for every site. The effect depends on how slow the site starts, how much of the traffic is on phones and which step of the journey is slow. Published results range widely: Vodafone's 31% faster LCP brought 8% more sales, and in the Deloitte study a 0.1-second gain came with 9.2% more retail spending. Any percentage applied to your site without your own data is a guess, so measure conversion by speed group in your analytics first.
No. Lighthouse runs one lab test on a simulated device and network, while Google judges Core Web Vitals on real visits at the 75th percentile. A page can score above 90 in the lab and still fail in the field because many customers use older phones on mobile networks. The field data is in the top section of PageSpeed Insights and in the Core Web Vitals report of Search Console. Use the lab score to debug and the field data to decide.
Yes. In the Deloitte study, lead-generation sites saw 21.6% more visitors reach the form submission page after a 0.1-second speed gain. Vodafone's faster landing page improved its lead-to-visit rate by 15%. The method to price it is the same as for a shop: replace average order value with the average value of a lead, using your own close rate and deal size.
Your analytics show the change in conversion as soon as enough sessions have come through, usually within days on a busy site. The Chrome UX Report behind PageSpeed Insights and Search Console uses a rolling 28-day window, so the field data catches up over about four weeks. If you run a split test, keep it running for at least two full weeks so both versions see the same weekdays and weekends.
Related services
Related articles
AI
DesignWhat makes a landing page convert: 8 factors and 4 killers
Median landing page conversion sits at 6.6%, SaaS at 3.8%. The top quartile wins on message match, load time and form friction, then on design.
Web