A site that loads in one second converts roughly three times better than one that takes five. Not a nicer experience. Three times the sales, from the same traffic, the same ad spend, the same offer.
Nobody in most marketing teams owns that number. It sits in the gap between the people who set conversion targets and the people who maintain the codebase, and because it belongs to neither, it quietly costs money every single day without anyone noticing it's the reason.
The number that should be on every dashboardOne second versus five seconds
Here's the data, and it's blunter than most teams expect. A site loading in one second converts at roughly 30.5 sales per 1,000 visitors. The same offer, the same traffic, on a site taking five seconds or more, converts at around 10.8 sales per 1,000. That's not a marginal difference. That's the gap between a campaign that pays for itself and one that quietly doesn't.
Bounce rate moves in step. The probability someone leaves before the page finishes loading rises 32% as load time goes from one second to three. Stretch that to ten seconds and the increase in bounce probability is up to 123%. Every extra second isn't a minor inconvenience. It's a compounding tax on every visitor your campaigns are paying to bring in.
Three times the conversion rate isn't a UX nicety. It's the difference between a campaign budget that works and one that quietly doesn't.
The milliseconds matter more than people think
It's tempting to file this under "obviously, don't be embarrassingly slow" and move on. The data doesn't let you off that easily. Checkout and form-completion speed improvements as small as 100 milliseconds, roughly the blink of an eye, have been shown to lift conversion by around 1.55%. That's not a rounding error at scale. Across a meaningful volume of traffic, tenths of a second add up to real pipeline.
For context on where most sites actually sit: the average page load time across the top 100 websites globally is roughly 2.5 seconds on desktop and 8.6 seconds on mobile. Lean, well-built B2B and SaaS sites can hit sub-second load times. Heavier, plugin-laden marketing sites routinely sit well past the point where the data says you're losing conversions to it.
Nobody loses a deal to a slow page in a way anyone writes down. They just quietly stop converting, and everyone assumes the campaign underperformed.Why nobody catches this
Speed belongs to everyone, so it belongs to no one
This is the real reason the problem survives quarter after quarter. Marketing owns the conversion target but not the codebase. Engineering owns the codebase but is rarely measured on conversion rate. Design owns the experience but tends to get graded on how the page looks in a review, not how fast it actually paints in a browser. Speed sits in the white space between all three functions, and white space is exactly where problems live forever, because fixing it isn't clearly anyone's job.
Compare that to a campaign that underperforms for an obvious reason, wrong audience, weak offer, bad creative. Someone owns that miss and someone fixes it. A slow page produces the exact same symptom, fewer conversions than it should, but with no obvious owner and no line in a report that says "page speed" as the cause. So it persists, silently, campaign after campaign. It's the same blind spot that let a landing page sit in review for six weeks before anyone asked whether the delay itself was the thing losing the campaign money.
The excuse that doesn't hold up"Fast and well-designed are a trade-off"
This is the assumption that lets the problem survive the longest, and it's mostly false. Look at what actually slows most B2B marketing sites down: a tag manager carrying eighteen months of scripts nobody's audited, unoptimised hero images shipped straight from a photographer's file, a page builder rendering more markup than the page needs, and third-party widgets loaded on every page whether or not that page uses them.
None of that is the design. It's accumulated weight the design is dragging behind it. A well-built, visually rich page and a fast page aren't in tension, they're both a function of how cleanly the thing was built in the first place. Static HTML and lean, framework-agnostic builds can look exactly as considered as a heavy CMS page, while loading in a fraction of the time, because there's simply less unnecessary weight for the browser to fight through. It's the same principle behind why escaping a rigid CMS tends to speed a site up rather than just make it easier to edit.
Where the weight actually comes fromThe five usual suspects
Third-party script bloat
Tag managers accumulate scripts the way garages accumulate boxes. Most marketing sites are running tracking and widget code nobody's audited in a year, each one adding its own request and its own delay.
Unoptimised images
A hero image straight out of a camera or a stock library can be ten times the file size it needs to be, with no visible difference to a visitor once it's properly compressed and sized.
Render-blocking CSS and JavaScript
Code that has to load and execute before the page can paint anything, often carried over from a template that loads everything upfront rather than what the visible page actually needs first.
Heavy CMS overhead
Page builders and plugin-based CMSs render far more markup than a hand-built page needs, and that overhead exists on every single page load, for every single visitor.
Missing caching and CDN setup
Serving every request from scratch, from a single origin server, when a content delivery network would put the page a fraction of the distance away from the visitor loading it.
Fix these five and most of the gap between "average" and "genuinely fast" closes, without touching a single word of the copy or a single pixel of the design.
Running the numbersWhat this actually costs a real campaign
Take a campaign sending 5,000 visitors to a landing page, at the industry average conversion tied to a five-second load: roughly 54 conversions, using the 10.8-per-1,000 figure. Get that same page to load in one second and the same traffic converts at closer to 152. That's not a marginal optimisation. That's nearly three times the pipeline from the exact same media spend, purely from how fast the page painted.
Now price it in pounds. If each of those conversions is worth even £200 in pipeline value, the gap between the slow version and the fast version of that one page is close to £20,000, on a single campaign, from a single landing page. Multiply that across every campaign a team runs in a year and the number stops being an interesting statistic and starts being a line item somebody should be accountable for.
This was never "nice to have a fast site." It's "which version of this campaign's results do you want," because the traffic and the spend are identical either way.
What Zenlio Studio does about it, as standard
Every Zenlio Studio build defaults to clean, framework-agnostic HTML and CSS, with a performance budget set before a single page ships, targeting a Lighthouse performance score above 90. Speed isn't an optimisation pass done after launch when someone finally notices the bounce rate. It's a launch requirement, the same as the copy being approved or the tracking being wired up correctly.
That's not a special add-on tier. It's what "static HTML where it makes sense" actually buys you: a page that loads in a fraction of a second by default, because there was never any unnecessary weight built into it in the first place.
Nobody in your org is measured on page speed.
That's exactly why it's worth fifteen minutes of somebody's time this week. Pull up your slowest landing page, check the load time, and multiply the gap by what a 3x conversion difference would be worth on your last campaign. That number is the actual argument for fixing it.