Building for the connection people actually have
A page that is quick on the machine it was built on and unusable on a five-year-old handset over mobile data has not been optimised. It has been measured in the wrong place.
3 min read
In short
How do you optimise a website for slow mobile connections?
Measure on the hardware and network your audience uses rather than in a lab, then cut what is heavy before tuning what is small. Server-render the content so the first paint does not wait on JavaScript, hold images to the sizes actually displayed, and treat the primary action of the page as the thing that must be interactive first.
The measurement is taken in the wrong place
A site is built on a fast machine on fibre, tested in a browser on the same machine, and scored by a tool running a synthetic profile. Then it is used on a handset several generations older, over mobile data, in a place where the connection drops in lifts and stairwells.
Those are different products. The gap between them is not a rounding error, and no amount of improving the first number guarantees anything about the second.
Weight first, cleverness second
The largest wins are almost never micro-optimisations. They are structural: what renders on the server rather than the client, how much JavaScript has to arrive before content is readable, and whether images are being sent at several times the dimensions they are displayed at.
Server rendering matters most on slow connections because it decouples reading from executing. Content that is present in the initial document can be read while everything else is still arriving. Content assembled in the browser cannot.
Data has a price the developer is not paying
Where connectivity is bought in bundles, page weight is money. A homepage carrying several megabytes before it is usable is asking a visitor to spend something to find out whether the site is worth visiting, and many of them will not.
This reframes the autoplaying hero video, the sixteen web fonts and the analytics stack. Each is a cost transferred to the visitor, and unlike a slow page it is a cost they cannot get back by waiting.
Design for the connection dropping
Assume interruption. A form should not lose what somebody typed because a request failed. A player should say the signal is unavailable and offer a retry rather than spinning. A page that has loaded should keep working.
These are not exotic requirements. They are the ordinary conditions of mobile use in most of the world, and treating them as edge cases is how a site becomes usable only in the places it was built.
What to measure instead
Field data from real sessions, segmented by device class and connection type, is the only number that describes your audience. A lab score is useful for catching regressions and useless for telling you whether people can use the site.
Pair it with the bill. A page can be fast and cost more to serve every month than it needs to, and the same duplicated work usually causes both.
Questions
Is a Lighthouse score a good performance target?
It is an instrument, not a result. Use it to catch regressions between builds. For deciding whether your audience can actually use the site, field data from real devices and connections is the only number that answers the question.
What single change helps most on slow connections?
Server-rendering the content, so reading does not wait on JavaScript executing. After that, holding images to the dimensions they are displayed at, which is usually the largest remaining weight on a page.
Related
- Performance and cost
Performance work that ignores the invoice is half the job.
- Product engineering
A demo is the twenty per cent of a product that is easy to show. We are usually hired for the rest.
- Khendo FM
A radio station whose website is part of the transmission rather than a poster for it.
- COFEK
A rebuild of cofek.africa for the country’s consumer watchdog, an organisation whose credibility is the product.