The Role of Speed in Conversion, Backed by Data

Everyone in web work has seen the studies claiming that every fraction of a second of load time costs some percentage of conversions. I’m not going to cite any of them, partly because I can never remember which ones held up, and partly because I think leaning on them misses the point. The interesting question isn’t whether some retailer’s number transfers to your site. It’s why speed affects conversion at all, and how you’d find out what it costs you specifically. Both questions have better answers than a borrowed statistic.

Start with why. The naive model says slow pages lose visitors because people get bored and leave, as if patience were a battery that drains at a fixed rate. Some of that happens. But I think the bigger effect is subtler: waiting is where doubt happens. A visitor who clicks a link has, at that moment, a small amount of intent. Intent is not a stable quantity. It decays, and it decays fastest when the visitor has nothing to do but reconsider. A page that loads instantly catches the intent while it’s still warm. A page that takes four seconds gives the visitor four seconds to remember the other tabs, the notification that just buzzed, the fact that they weren’t that sure about this anyway. The page isn’t just late. It’s late to a mind that has moved on.

There’s a second mechanism, which is inference. Visitors read speed as a signal about the organization behind the page. This isn’t irrational. A checkout that lags makes people wonder whether the payment will go through. A dashboard that stutters makes people wonder what the backend looks like. Speed is one of the few quality signals a stranger can evaluate in the first second, before reading a word, so it carries more inferential weight than it logically should. You can’t tell a visitor your engineering is careful. A fast page tells them.

And there’s a third mechanism that gets less attention: slowness compounds across a funnel. A single page that takes three seconds is an annoyance. A five-step checkout where every step takes three seconds is fifteen seconds of accumulated waiting, distributed across exactly the moments when the visitor is deciding whether to continue. Funnel abandonment gets blamed on form length and pricing shock, and those matter, but some fraction of it is just latency, paid in installments.

Now the measurement question, which is where “backed by data” should actually point: your data, not the industry’s. Most analytics setups already record, for each session, some measure of page load time and whether the session converted. That means you can do the study yourself. Bucket your sessions by load time, fast, medium, slow, and compare conversion rates across buckets. If the rate falls as load time rises, you have your own curve, for your own site and your own audience, which beats any published benchmark.

You have to be honest about one trap, though: correlation runs both ways here. Slow sessions convert worse partly because slowness repels, but also because slow sessions cluster among people on weak connections and old phones, who may differ from your other visitors in ways that independently affect buying. The clean way to untangle this is to make the site faster and watch what happens to conversion, which turns the correlation into something closer to an experiment. Conveniently, this is also just the thing you wanted to do anyway. Speed improvements are among the few conversion changes with no downside to test. Nobody converts less because the page loaded faster.

Where do you look first? The usual suspects account for most of it: images shipped at several times their display size, third-party scripts, especially analytics and chat widgets, each of which some team added for a reason and none of which anyone ever removes, and render-blocking resources that force the browser to sit on a blank screen while it fetches stylesheets and fonts. What makes these persistent isn’t that they’re hard to fix. It’s that they’re invisible to the people who own the page. Your team loads the site over office broadband on machines with everything cached, so it feels instant to everyone with the power to fix it.

That invisibility is why I made GazeSite record a HAR file, a log of every network request the page makes, alongside its screenshots when it audits a site. The screenshot shows what a visitor sees; the network capture shows what they waited through to see it, every script and image and font, with sizes and timing. Site owners are routinely startled by their own request list. Not because any single entry is shocking, but because nobody had looked at the whole list in years, and it had grown the way all unwatched lists grow.

So skip the borrowed statistics. Run the two-part exercise instead: bucket your own sessions by speed and look at the conversion curve, then load your own site the slow way, on a phone, on cellular, cache cleared, and feel the wait your visitors feel. The data tells you what speed is worth. The wait tells you why.