Field staff often open a website on a phone, on a weak signal, in the middle of something else. If the page takes a minute, it does not get read. This piece is for teams commissioning or building a site for people in low-bandwidth settings, and it sets out how we choose a limit and hold to it.
Pick the number first
web.dev defines a performance budget as “a set of limits imposed on metrics that affect site performance”. Its suggested starting point is under 170 KB of critical-path resources and under five seconds to interactive, worked out for baseline devices on a 3G network.
Compare that with the web as it is. The HTTP Archive’s Web Almanac put the median home page in 2025 at 2.86 MB on desktop and 2.56 MB on mobile. On a slow connection of 400 kilobits per second, 2.56 MB takes about 51 seconds to arrive, before any delay from the network itself.
We work to 500 KB a page. That is about ten seconds at the same speed: slow, but usable. It leaves room for one good photograph and a set of web fonts, which matters when the site also has to look like the organisation that runs it.
“A budget nobody checks is a wish. It has to be measured, on every release, by someone who can stop the release.”
Measure it the way it will fail
A single figure from a desktop browser hides most of the problem. These are the checks that have caught real overruns on our projects:
- As it opens. Use an empty cache and count the bytes that travel, not the size of the files on the server.
- Scrolled to the end. Lazy loading delays images, it does not remove them. A page can pass as it opens and fail by the bottom.
- On a high-density phone. Two-times and three-times screens ask for larger images, so the same page can weigh far more than it does on a laptop.
- With JavaScript off. Lazy loading that depends on a script stops, and every image on the page may load at once.
Put it in the contract
Write the limit into the brief, with the method for measuring it. Then each new feature has a price the whole team can see. When something goes over, web.dev gives the three honest choices: optimise it, remove it, or do not add it.
The discipline pays for itself in the first emergency that sends a new audience to the site on phones and poor connections. By then it is too late to start.