By Mehdi HassanDoes website speed affect conversion rate?
Yes, website speed affects conversion rate: in controlled tests, adding delay to a page reduces conversions. What the evidence doesn't support is a universal rule, such as a fixed percentage lost per second, that applies to every site.
That distinction matters because most of what you read about speed and sales comes from vendors selling speed. Their numbers are often real figures from one company's data, stripped of context and repeated until they sound like laws. This piece separates what's well supported from what isn't, so you can decide how much speed work your site actually needs. For the metrics themselves, start with our guide to Core Web Vitals for marketers and founders.
Where do the famous speed statistics come from?
Most famous speed statistics come from a handful of retail and media studies from years ago, and many are now quoted wrongly. The best-known example is the claim that every one-second delay costs 7% of conversions.
That figure is usually traced to SOASTA's retail data, but the original data actually showed a drop of around 7% for a 100-millisecond delay and around 20% for one second. So the popular version misstates the delay by a factor of ten, while the underlying finding is about one retail data set, not your SaaS homepage.
Claim you'll see | What we found | How to treat it |
|---|---|---|
"1 second delay = 7% fewer conversions" | Misquotes SOASTA, whose data showed about 7% at 100ms and about 20% at 1s | Don't repeat it as a rule |
A SiteSpect controlled test | Measured an effect of about -4.4% on mobile conversions | Stronger method, smaller effect |
Vendor case studies ("we cut load time and sales doubled") | Usually one client, many changes shipped at once | Anecdote, not evidence |
Lab scores tied to revenue | Lab scores don't measure what real visitors experienced | Look for field data instead |
Notice the pattern. The more careful the method, the smaller and more specific the effect tends to be. That doesn't mean speed is unimportant. It means the honest answer is "it depends", and you should know on what.
What does the stronger evidence actually show?
The stronger evidence shows a real but moderate link: slower experiences reduce conversions, the effect is larger on mobile, and it varies by context. Controlled tests, where only speed changes, are the ones worth trusting.
A controlled test deliberately slows down a random share of visitors and compares their conversion rate with everyone else's. Because nothing else changes, the difference can be attributed to speed. SiteSpect's test, which found an effect of about -4.4% on mobile, is that kind of evidence, and its result is far more modest than the numbers passed around on social media.
Before-and-after stories are weaker. When a team rebuilds a site, it usually changes the design, copy, offer and tracking at the same time as the speed. Any lift belongs to all of those changes together. Our companion piece on page speed and conversion rate data goes through more of the numbers in detail.
The more careful the study, the smaller and more specific the speed effect tends to be.
Why should you distrust vendor speed stats?
You should distrust vendor speed stats when they come without a method, a sample and a date, because without those you can't tell whether the number applies to you. A speed vendor has an obvious reason to publish the most dramatic figure it can find.
Ask four questions of any statistic before you put it in a deck. Who measured it, and do they sell speed? Was it a controlled test or a before-and-after comparison? What kind of site and traffic was it, and is that like yours? And how old is it, given how much devices and networks have changed? If a claim can't answer those, treat it as a story, not a forecast.
When does speed matter most for conversions?
Speed matters most when pages are already slow, when most visitors are on phones, and when you pay for every visit. In those cases even a moderate effect on conversion rate is worth real money.
- Already-slow pages. Going from very slow to acceptable is likely to matter more than going from fast to slightly faster. Google's Core Web Vitals thresholds are a sensible line for "acceptable".
- Mobile-heavy traffic. The SiteSpect result was measured on mobile, where slower devices and networks make delays more noticeable.
- Paid landing pages. Every visitor who leaves before the page loads is a click you paid for.
- Responsiveness, not just loading. A page that loads quickly but lags when someone taps a pricing toggle or form field frustrates people at the moment they're deciding. That's what INP measures.
- Heavy third-party scripts. Chat widgets and testing tools often cause the lag. See our third-party script audit method.
Speed matters less when a page already passes Core Web Vitals and loads quickly on a mid-range phone. At that point, the next gain is almost always in the offer, the copy and the proof.
How can you test speed's effect on your own site?
You can test speed's effect on your own site by comparing real-user speed data with conversion data, or by running a controlled delay test if you have enough traffic. Your own numbers beat any industry statistic.
- Get field data. Use Search Console's Core Web Vitals report or real-user monitoring, not just lab scores. Our guide to PageSpeed Insights scores versus real-user data explains the difference.
- Make sure conversions are tracked properly. Speed analysis is useless if form submissions and demo bookings aren't recorded reliably. See conversion tracking for lead-gen websites.
- Segment by speed. Compare conversion rates for fast and slow sessions on the same page. It's correlation, not proof, but it shows whether the issue is worth pursuing.
- Run a controlled test if traffic allows. Add a small artificial delay for a random share of visitors and compare. Most startup sites don't have the traffic for this, and that's fine.
Hypothetical example: reading your own data
For example, suppose a startup sees that its pricing page passes Core Web Vitals on desktop but fails INP on mobile, and that mobile visitors convert at a lower rate. That gap could be speed, or it could be that mobile visitors are earlier in their research.
The team fixes the slow interaction (a heavy chat widget firing on load) and watches mobile conversion for the following weeks. If mobile improves while desktop stays flat, speed was likely part of the problem. If nothing moves, the next place to look is the mobile layout and copy.
Should you fix speed or the page itself first?
Fix speed first if the page is clearly slow or fails Core Web Vitals; otherwise fix the message first. A slow page loses people before they read anything, but a fast page with a vague headline loses them right after.
In our projects we treat them as one job. The copy decides what goes above the fold; design decides how heavy that content is; code decides how quickly it appears. Working out a fair target for conversion rate also helps, and our landing page conversion rate benchmarks give context for that.
