Designing software for the networks people actually use
Fast fibre in an office is not the test. A mid-range Android phone on a busy mobile network is. Here is how we set performance budgets.
NWEE Engineering1 min read
In many of the markets we build for, most people reach the internet through a phone, on mobile data they pay for by the megabyte. Software that feels fast on an office connection can feel broken on the bus. We design for the second case first.
Budgets, not good intentions
Every product we build starts with a performance budget: how many kilobytes a page may weigh, how long the first meaningful content may take to appear, how much JavaScript must run before a user can act. The budget is checked automatically on every release, so it cannot quietly erode.
Resilience is a feature
Connections drop. Forms should keep what a person typed. Actions should be safe to retry. Screens should say clearly what failed and what to do next. These details rarely appear in a specification, but they decide whether people trust a system.
Designing for constrained conditions does not produce second-class software. It produces software that is faster and more reliable for everyone, including users on fast networks elsewhere in the world.