Performance
The four seconds that cost you half your visitors
What actually makes a page slow, measured on real sites rather than in a lab, and the three fixes that account for most of it.
- Performance
- 6 min read
"Slow" is a word clients use and a measurement we have to make specific before it means anything. Slow compared to what? Measured where? On whose connection? Lab tools like a local Lighthouse run on a fast office connection tell you almost nothing about what a real visitor on a mid-range phone, on mobile data, three time zones away, actually experiences. The gap between the two is usually the whole story.
What the real-world data says
Across the sites we have instrumented with real-user monitoring rather than lab tests, the pattern repeats: bounce rate climbs sharply once a page passes about four seconds to become usable, and it keeps climbing from there. Not four seconds to fully finish loading — four seconds until the visitor can read the headline and tap something. Past that point you are not looking at a UX problem anymore, you are looking at a business problem: half the people who typed in your URL or clicked your ad never saw the page you spent money getting them to.
The three things that actually cause it
Images sized for the wrong screen
The most common single cause we find is a hero image exported at desktop resolution and served, unscaled, to a phone. The browser downloads the full file and shrinks it visually — the visitor pays the download cost of an image four times larger than the screen it is displayed on. Serving a properly sized, modern-format image is usually the single biggest fix available on any given page, and it is almost always free to make.
Fonts blocking the first paint
A custom typeface is worth something to a brand. A custom typeface that blocks the page from rendering anything until it downloads is worth nothing to the visitor waiting on a blank screen. The fix is not "stop using custom fonts" — it is loading them in a way that lets the browser show text immediately in a system font and swap in the real one when it arrives, so nobody stares at nothing while a font file crosses the network.
Third-party scripts nobody remembers adding
Analytics tags, chat widgets, an A/B testing tool from a project that ended two years ago, a retargeting pixel added once and never removed — each one is small individually and the combined weight is not. We regularly find sites running six or seven third-party scripts where two are actually used. Every one adds a network request and, more often than the vendor admits, blocks the main thread while it initialises.
What we actually do about it
Fixing this is not a redesign. It is auditing what is currently on the page, removing what nobody is using, sizing images for the device that requests them, and loading fonts so they never block text from appearing. On most sites we take on for a performance pass, those three changes alone move the real-user load time from somewhere past four seconds to comfortably under two — without changing how the site looks.
Ready when you are.
Tell us what you're building and we'll map the shortest route there.
Keep reading