Faster pages tend to convert better, but the size of the gain depends on how slow you started.
The cleanest evidence comes from controlled experiments: Bing found every 100 milliseconds of speed was worth 0.6% of revenue, and Vodafone's A/B test of a 31% faster Largest Contentful Paint produced 8% more sales.
Store-level results in our database range from single digits to over 40%, and most of the big numbers come from rebuilds that changed more than speed.
This page sorts the evidence by quality. Speed experiments that hold everything else constant come first, then A/B tests of lighter builds, then before/after redesigns, which are the most common and the least reliable.
Core Web Vitals and conversion: what the metrics measure
Google's Core Web Vitals are three field metrics.
Each has a "good" threshold that Google says sites should hit at the 75th percentile of page loads, measured separately on mobile and desktop.
| Metric | What it measures | Good | What a shopper notices |
|---|---|---|---|
| Largest Contentful Paint (LCP) | Loading: when the main image or text block appears | 2.5 seconds or less | A blank or half-built product page |
| Interaction to Next Paint (INP) | Responsiveness: delay between a tap and the screen reacting | 200 milliseconds or less | Variant pickers and add-to-cart buttons that feel stuck |
| Cumulative Layout Shift (CLS) | Visual stability: how much content jumps around | 0.1 or less | Tapping the wrong button because a banner loaded above it |
INP replaced First Input Delay as a Core Web Vital in 2024. If an older guide talks about FID, its advice on interactivity is out of date.
The best published link between a Core Web Vital and sales is Vodafone's test.
It split paid traffic 50/50 between two landing pages that looked and worked the same.
The faster one moved widget rendering to the server and optimized images, which cut LCP from 8.3 to 5.7 seconds (31%).
It produced 8% more sales, a 15% higher lead-to-visit rate and an 11% higher cart-to-visit rate.
One detail matters: the faster page actually had a 15% worse DOMContentLoaded time.
The metric the user perceives (when the main content shows up) predicted sales. A generic technical timing did not.
Lab scores such as Lighthouse or PageSpeed Insights are a diagnostic, not the target.
A Lighthouse run is one simulated load. Core Web Vitals are judged on real visits, which include old phones and slow networks.
Page load time and conversion rate: the controlled evidence
The strongest studies slow a page down on purpose for a random group of users.
Nothing else changes, so any drop in revenue is caused by the delay.
- Bing. In a two-week experiment, Bing slowed 10% of users by 100 milliseconds and another 10% by 250 milliseconds. Ron Kohavi and colleagues reported in their KDD 2013 paper that "every 100msec improves revenue by 0.6%." The same paper cites Greg Linden's report that a 100-millisecond slowdown at Amazon cut revenue by 1%.
- Etsy. The same paper notes that Etsy reported a 200-millisecond delay did not matter. The authors' view is that Etsy's test probably lacked the statistical power to detect a small effect, not that speed is irrelevant.
- Deloitte for Google. The 2020 Milliseconds Make Millions report found that a 0.1-second improvement in mobile site speed went with 8.4% more retail conversions and 10.1% more travel conversions. This was an observational study across brands, not a randomized test, so read it as correlation. The same report cites Google data from 2017 showing that bounce probability rises 32% as mobile load time goes from 1 to 3 seconds, and 123% from 1 to 10 seconds.
Two lessons come from this. First, small delays have small effects, often under 1% per 100 milliseconds.
A large site can detect that. A store with 20,000 sessions a month cannot.
Second, the effect is not linear. Going from 8 seconds to 5 matters far more than going from 1.8 to 1.5.
You will also see the claim that 53% of mobile visits are abandoned when a page takes over 3 seconds.
It comes from 2016 Google data, and the original page no longer loads. We don't use it.
Site speed and conversion: what our database shows
LiftArchive tags tests under themes and page speed whenever a lighter build, a theme change or a speed project was part of the change. They fall into three tiers of evidence.
A/B tests where the build was the main difference
These come closest to isolating speed, though none of them measured load time alongside conversion.
- Oliver Kenyon rebuilt a client's best landing page natively in Shopify and tested it against the identical page in a landing page builder. Same copy, images, structure and offer. The native build won with +9.9% conversion rate and +20.9% revenue per visitor. Oliver Kenyon's explanation was that the native page is "faster, lighter, more responsive."
- Vasta replaced a third-party app header with a theme-native header for Canada Welding Supply. The app header added extra JavaScript, overlapped the search bar and had cramped tap targets. In a 50/50 split over 14 days, the native header won with +17.02% conversion rate and +6.44% revenue per visitor. Layout fixes shipped with the speed gain, so the two can't be separated.
- Peter Christensen moved a $600+ AOV offer from SamCart to a PageDeck landing page and saw a +20% conversion rate delta. Peter Christensen reported it as pulling ahead that month, without a significance figure.
- Kasper Dolk tested a new Shopify theme against the old one. Conversion rate went from 2.44% to 3.53% (+44.54%) and revenue per visitor from £1.08 to £1.54, at a 99.7% probability to beat the old theme. The new theme also carried a buy-one-get-one offer, so this is a theme-plus-offer result, not a speed result.
Speed projects measured before and after
- Vasta raised an anti-aging supplement brand's mobile Lighthouse score from 35 to 92 on the homepage and from 30 to 91 on product pages, mostly by cutting heavy third-party scripts and layout shift. Conversion rate rose 20% and total sales 13%. This is the purest speed-only project in our database, but it was a before/after comparison, not a split test.
- Clean Commit's mobile checkout overhaul doubled orders (+100%) despite 12.2% fewer visitors. Faster mobile pages were one part of it, alongside fewer form fields and a simpler payment flow. Clean Commit notes the control had close to zero mobile conversions, so this was fixing a broken flow, not a typical result.
Redesigns sold as speed wins
Many agency case studies credit speed for a redesign result.
Blend Commerce's Goat Milk Stuff rebuild reported +22% conversion rate and a bounce rate drop from 62.29% to 55.05%.
But the launch also added a product quiz, subscriptions, a free booklet and farm pickup.
Blend Commerce's Aquarium Co-Op redesign reported +18% conversion rate comparing Q1 2021 with Q4 2020, while sessions rose 73% and seasonality was not controlled.
These results are real for those stores. They just don't tell you how much of the lift came from speed.
@oliverkenyon
VastaVasta
Clean Commit
@kasper_dolk
@peterac_What to fix first, and how to measure it
The pattern across these tests is consistent. The wins came from removing weight: app scripts, page-builder code, third-party headers.
They did not come from shaving the last few hundred milliseconds off a page that was already fast.
- Check field data, on mobile. Look at LCP, INP and CLS for your product and collection pages from real visits. If they are already in the "good" range, speed is unlikely to be your biggest lever. Look at mobile UX or offer tests instead.
- Audit third-party scripts and apps. Each review widget, popup, chat tool and tracking pixel adds JavaScript. The anti-aging supplement and Canada Welding Supply results both came from removing this kind of weight.
- Move proven landing pages off heavy builders. Builders are good for fast iteration. Once a page wins, a native rebuild is worth testing, as Oliver Kenyon's result shows.
- Watch your testing tool. Client-side A/B testing scripts can slow the page and cause flicker, which hurts the variant you are measuring.
To measure the effect, split traffic between the current page and a lighter version that looks the same, as Vodafone did.
If you can't split, at least compare the same weeks year over year and log every other change that shipped.
Track load time as a guardrail metric on every test, so a winning feature doesn't quietly slow the site.
When speed is the wrong thing to work on
- Your pages already pass Core Web Vitals. Returns shrink as pages get faster. A copy, offer or product page test will usually teach you more.
- You have low traffic and want to prove a small gain. A 100-millisecond change worth under 1% needs very large samples. Etsy's null result shows how easy it is to miss a real effect.
- The "speed" project is really a redesign. If you change the layout, offer and theme at once, credit the result to the bundle. Don't plan your next project on the assumption that speed did it.
For more on where speed fits in a wider program, see our CRO guides or browse the full test database.