Skip to content
Web

Does 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.

October 26, 2026 · 8 min read

Two identical dark page cards side by side, split by a dashed line; the left card carries a long lit load bar and the right a short one, and under each card a grid of eighteen slots, nine lit under the slow page and fifteen lit under the fast one

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:

  1. 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.
  2. The device mix. Phones on mobile networks wait longest, which is why every study above measured mobile traffic.
  3. 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.

  1. 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.
  2. 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.
  3. 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.
  4. 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

Frequently asked questions

Related articles

Studio

Start a project.

We write about what we build. Tell us what you want to build.