Speed and conversion rate: what the studies say
What reported studies say about site speed and sales, what they cannot prove, and a six-step way to test the effect on your own pages with real visitors.
In this guide
What the reports found
Milliseconds Make Millions
The largest is a study that Google commissioned from two companies, 55 and Deloitte. As web.dev describes it, the team studied 37 European and American brand sites, with data from over 30 million user sessions. No redesigns happened on those sites during the study. Mobile load times were monitored hour by hour for 30 days at the end of 2019, and compared with revenue-related numbers from each brand's analytics.
Its headline is a 0.1 second improvement in four speed measures, which web.dev lists as First Meaningful Paint (now deprecated), Estimated Input Latency, observed page load time and server latency. Every page along the journey had to improve each measure by that much. Web.dev reports these results by type of site:
| Type of site | What changed with a 0.1 second gain |
|---|---|
| Retail | Conversion up 8.4%. More people moved from product list to product page (3.2%) and from product page to basket (9.1%). Spending rose 9.2% |
| Travel | Conversion up 10.1%. Check-out completion up 2.2% and bookings up about 10% |
| Lead generation | The share of visitors reaching the form submission page rose 21.6%, and page views rose 7% |
| Luxury | The biggest changes, such as 40.1% more movement from product page to basket, on small starting rates |
Core Web Vitals examples
A second web.dev article, from 2021, collects what individual companies reported after improving their Core Web Vitals:
- Vodafone (Italy) improved Largest Contentful Paint by 31% and reported 8% more sales. It measured this with an A/B test, and its advice was that a server-side test is the best way to see the real effect.
- iCook improved Cumulative Layout Shift by 15% and reported 10% more ad revenue.
- Tokopedia improved LCP by 55%, from 3.78 seconds to 1.72, and reported 23% better average session duration.
- Redbus cut layout shift from 1.65 to 0 and reduced interaction delays, and reported an 80 to 100% increase in mobile conversion rates.
- Other examples in the article: Netzwelt reported 18% more ad revenue, Lazada made LCP three times faster and reported a 16.9% rise in mobile conversion, and GYAO made LCP 3.1 times faster and reported a 108% rise in click-through rate.
How to read them
These are real results, but they are not promises.
- Who ran them. Google commissioned the first study and published both articles. That does not make them wrong. It does mean they were chosen to make a point.
- What was fixed. The sites that report big gains usually had real problems. A page that is already fast has less to gain.
- What moved together. The first study watched speed and revenue measures change over time. It shows a link. It cannot tell you which pages on your site, for your visitors, will respond.
- The conditions. The gains needed every page on the journey to be faster. web.dev's own method article warns that a faster product page may do little if the checkout is slow or unfriendly.
- The year. The numbers come from 2019 to 2021. Phones, networks and expectations have changed.
Take from them a direction and a reason to measure, not a number to promise a client or a boss.
Test it on your own site
web.dev's article on relating site speed and business metrics describes a method in six steps. This is a short version.
- Pick one page. It should be on mobile, because phones are more sensitive to slow pages. It should matter to your conversion funnel, have a single purpose, get enough traffic to give a clear answer in a reasonable time, be relatively slow, and stay stable while you test. A product page, a landing page or a form page often fits.
- Measure in the field. web.dev recommends real user monitoring, because it reflects what real visitors get, and starting with the Core Web Vitals. See real user monitoring and lab and field data.
- Make a faster version that looks the same. Change nothing visible. The article's examples include compressing images, removing unused code, loading third-party scripts efficiently, inlining critical CSS and lazy loading.
- Split the traffic. Send half the visitors to each version. web.dev recommends a server-side test where you can, because many client-side tools hide the page until the experiment loads, which skews the speed you are trying to measure.
- Analyze. Compare the business numbers that matter, such as conversions, conversion rate, page views or revenue. Add bounce rate and session duration. Look at mobile alone, leave out bots, and, if you have the data, split by region, network, device and new against returning visitors.
- Decide. If speed and results clearly move together, report it in business terms and set a performance budget. If not, check the article's caveats before deciding that speed does not matter.
The caveats in the article are useful. A test may show nothing because the page has too little influence on the metric, because the two versions are not different enough in speed, because the test setup is faulty, or, rarely, because your visitors are not sensitive to speed. To rule out a faulty setup, the article suggests an A/A test: send two groups to the same page and check that the numbers match.
A first look without a test
If you cannot run a test yet, you can still look. Using your real-user data, group page visits by how fast the page loaded, such as Largest Contentful Paint under 2.5 seconds, between 2.5 and 4, and above 4, and compare the conversion rate in each group. Treat the result as a hint. Visitors on fast phones and networks may differ from the others in ways other than speed, so a gap here is not proof, and the A/B test remains the better evidence.
You can also compare a period before a change with the period after. That is weaker still, because seasons, campaigns and prices change as well. Keep a record of what else moved, as the guide on testing speed changes safely suggests.
What to do with the answer
- Fix the biggest delay first. See what to fix first.
- Watch the whole journey. A faster page followed by a slow checkout recovers little. See online store speed.
- Set a budget so that speed does not slip back. See automated testing and budgets.
Mistakes to avoid
- Quoting a study as a promise.
- Testing on a fast page, where there is little to gain.
- Testing with a tool that hides the page until it loads.
- Changing the design and the speed together, which makes it impossible to tell which one worked.
- Stopping the test early.
- Counting bots and desktop visits in a mobile test.
- Judging a speed change by one day of sales.
Check your own page
Run the free audit on the page that matters most to your sales, and write down its Largest Contentful Paint. Then choose the business number you would watch, such as completed forms or orders, and find out where you can see it by page and by device.
Sources
- Milliseconds make millions on web.dev: the study of 37 brand sites and its results by type of site.
- The business impact of Core Web Vitals on web.dev: the Vodafone, iCook, Tokopedia, Redbus and other examples.
- Relating site speed and business metrics on web.dev: the six-step testing method and its caveats.
Start here
Free website audit
Live Google data for any public page: mobile and desktop.
Mobile + desktop · Lighthouse lab test · Real-user Chrome data when Google has it
Rather have this done for you? Speed optimization · Book a call