Page speed as a conversion lever: how much is it really worth to you?

You'll have read that every extra second of load time costs some percentage of conversions. Those studies exist, but they're averages across other people's sites, measured at speeds that may look nothing like yours. The question worth asking is narrower: from where your site is right now, what would a specific improvement be worth, and is it the best use of that effort?

The headline statistics hide the shape of the relationship. Going from one second to two costs you relatively little, while going from five to six costs a great deal more, because somewhere in that range people give up and leave.

So start by finding out where you sit, measured on mobile over a real connection. Your office wifi with everything already cached will flatter you.

If your mobile pages load in about a second and a half, further page speed work is proper engineering effort for a small return, and you'll almost certainly get more out of spending that time elsewhere. Above four seconds it's the other way round: you're losing visitors before they've seen anything, and nothing else you test will matter much until that's fixed.

The segment that suffers most is paid social on mobile. Those people arrive mid-scroll, on a phone, often on mobile data, with less patience than any other traffic you have, and you paid for each one of them.

A slow site can convert organic search reasonably well and still burn through paid clicks. In your reports that looks like a media problem, when the cause is the site. So look at the right number before deciding anything: your site-wide average load time doesn't tell you much, while load time for paid mobile visitors is the figure that's costing you money.

There's no need to A/B test whether a faster site is better. You'd spend a month confirming something everyone already knows, and nobody doubts the mechanism.

What is worth doing is comparing your own numbers before and after. That's a sequential comparison, so it's weak evidence, and here that's acceptable: you aren't trying to prove cause and effect, only to see how big the change was on something you were going to do regardless.

An experiment does make sense when the fix costs you something. Removing a personalisation script, dropping a reviews widget or serving lower-resolution images all make the page faster, and they all take away something that might have been helping sales. That's a real trade-off, and it deserves a test with revenue per session as the primary metric.

Roughly in order of how often we see them:

• Product photos uploaded at print resolution. It's the most common cause by a distance, and the easiest to fix.
• Third-party scripts: chat widgets, review platforms, analytics, ad pixels, social embeds. Each is another request and some block rendering. Eleven scripts loaded through a tag manager is a lot of weight to carry, often for features nobody uses.
• Theme bloat. Bought themes come with carousels, animations and fonts you don't use, and the code loads whether or not those features appear on the page.
• Fonts: several weights from several families, all loaded in a way that blocks rendering.

None of these needs an experiment, just an afternoon.

If you add a testing or personalisation script to your site, it becomes part of the same sum. A tool that measurably slows your pages is clawing back part of what it gives you.

That's why the Bixlow loader is one small file, loaded asynchronously, and why it fails silently instead of blocking the page if it can't reach our servers. It's also why we integrate with Clarity rather than shipping our own session recorder; two recording scripts on the same page cost real load time for a capability you'd have twice.

Ask the same three things of any tool before you add it: how much does it weigh, does it block rendering, and what happens to your site when it fails to load?