Making Your Site Work on a Bad Connection
Development happens on fast machines on good connections, three feet from the router. Most website use does not.
The gap between those two environments is where a surprising share of lost business lives, and closing it is mostly about a handful of unglamorous decisions.
What a bad connection actually does
It isn't simply "slower." Poor mobile networks have high latency, meaning each request has a long fixed cost before any data moves, and connections drop and resume.
The practical consequence: number of requests matters as much as total size. A page pulling 60 separate files over a high-latency connection is slow even if each file is small.
The things that help most
Send less. Obvious, and still the biggest lever. Images correctly sized and compressed, unused CSS and JavaScript removed, fonts limited to the weights you actually use.
Send the important part first. Inline the small amount of CSS needed for what's above the fold, defer the rest. The visitor sees something real while the remainder arrives.
Make text appear without waiting for fonts. font-display: swap shows the fallback immediately. A brief flash of a different typeface is preferable to a blank page — the visitor can start reading.
Fail gracefully. If a script doesn't load, does the page still work? Navigation that requires JavaScript, forms that only submit via a fetch call, content injected client-side — every one of those becomes a blank page when the connection drops mid-load. Server-rendered HTML with progressive enhancement doesn't have this failure mode.
Cache aggressively. A returning visitor should re-download almost nothing. Long cache lifetimes on fingerprinted assets are free and dramatically improve the second visit.
Test the real thing
Browser network throttling is a decent approximation of bandwidth and a poor one of latency and packet loss. Better:
- Use a real phone on real cellular, and go somewhere with a weak signal on purpose.
- Test with JavaScript disabled once. You'll learn what the page's skeleton actually is.
- Test from far away. If your server is in Virginia and you have customers in Perth, they're experiencing a different website.
- Look at your field data segmented by connection type. The story is usually in there and nobody looks.
The point that persuades sceptics
This isn't charity for people with bad phones. On a typical service business site, mobile traffic is the majority and converts at roughly half the desktop rate. That gap is not a law of nature — a good part of it is that the mobile experience was never really tested.
Closing it is not a redesign. It's images, requests, fonts, and one honest test on a real phone in a bad spot.