There is a specific kind of website failure that never shows up in a design review. The site looks excellent. Everyone signs off. It launches. And the analytics show people arriving and leaving before anything appears on screen.
Nothing is broken. The site is just too heavy for the conditions it is actually used in, and nobody tested it under those conditions because everybody involved in building it had good hardware and a good connection.
The gap, concretely
The device your site was designed on and the device most of your visitors hold are not in the same category. A modern laptop on fibre will render almost anything instantly. A mid-range Android phone on mobile data is working with a fraction of the processing power, a fraction of the bandwidth, and meaningfully higher latency on every single request.
Latency is the part people underestimate. It is not just that the connection is slower, it is that every separate file the page asks for carries a round-trip delay. A page that requests sixty files pays that cost sixty times. This is why reducing the number of requests often matters more than reducing their size.
The test that costs nothing
Open your site on your own phone, on mobile data, with wifi switched off, somewhere with average signal. Not your developer's phone. Yours, in a normal place. If you find yourself waiting, so is everyone else, and most of them will not wait as patiently as you.
What actually makes pages slow
Images, almost always
Images are the single largest cause of heavy pages, and the fix is mostly mechanical. A photo straight off a camera or phone can be several megabytes. The same photo, correctly sized and served in a modern format, can be a small fraction of that and look identical on screen.
Three things to insist on:
- Correct dimensions. Do not upload a 4000px-wide photo to fill a 600px-wide space. The browser downloads all of it and then throws most of it away.
- Modern formats. Formats like WebP and AVIF are dramatically smaller than JPEG at the same visual quality, and every current browser supports them.
- Lazy loading. Images below the fold should not download until the visitor scrolls toward them. This is one HTML attribute and it is free.
Fonts that block the page
Custom fonts are usually loaded in a way that stops the page rendering until the font file arrives. On a slow connection that means a visitor stares at a blank screen while a decorative file downloads. Loading fonts so they never block rendering is a small change with a large effect, and it is one of the first things we fix on any site we inherit.
JavaScript you are not using
Every script has to be downloaded, parsed, and executed, and on a modest phone the parsing is often the expensive part. Sites routinely ship large libraries to power one small feature, or load analytics, chat widgets, and tracking pixels that together outweigh the actual page.
The question to ask about every third-party script is straightforward: what does this do for a visitor, and is it worth what it costs them to load?
Too many separate requests
Five stylesheets, eight scripts, three font files, and a dozen images is thirty round trips before the page is complete. Consolidating files and cutting anything unused is unglamorous work that consistently produces the biggest wins.
What good looks like
Reasonable targets for a content website serving an audience on mobile data:
- Something visible within about three seconds on a mid-range phone over mobile data
- Total page weight comfortably under a megabyte for a standard content page
- Nothing that blocks rendering in the initial load, including fonts
- Every below-fold image lazy-loaded, without exception
- Layout that does not jump as images and fonts arrive, which means setting image dimensions in the markup
None of these are exotic. They are the default outcome of building carefully, and the reason so many sites miss them is that nobody set them as a requirement at the start.
Why this is not just a technical concern
It is tempting to file performance under developer housekeeping. It is not. For an organisation whose audience is largely on mobile data, page weight is an access question. A heavy site quietly excludes the people on the worst connections and the oldest phones, who are frequently the people you most want to reach.
There is a cost angle too. In a lot of markets, mobile data is bought in bundles. A bloated page is spending your visitor's money to show them your content. That is worth taking seriously.
And search engines measure loading performance directly as a ranking input, so the slow version of your site is also the less visible version.
Ask for it explicitly
Performance is much cheaper to build in than to retrofit. Put it in the brief: "the site must show content within three seconds on a mid-range phone over mobile data." Any developer worth hiring will treat that as a normal requirement.
We build every site this way by default rather than selling it as an upgrade, because a site that is too slow for its audience has not really launched. If you want to see how we applied this to a real project, the Timoya Farms case study covers a build we deliberately kept framework-free for exactly this reason.
The same audience on mobile data is usually the same audience paying with Mobile Money rather than a card. If you are also thinking about payments, why Mobile Money changed what a website needs to do covers what that means in practice.