There is a version of your product that your team has never tested.
It is the version that loads on a bus in Lagos, on a construction site in Manila, in a hospital waiting room in rural Brazil, or on a prepaid data plan anywhere in the world where every megabyte has a cost attached to it. It is the version your user experiences when the connection drops mid-interaction, when the image never quite finishes loading, when the button they tapped appears to do nothing for three seconds and they tap it again.
Most product teams build for the version that loads instantly on a laptop connected to office WiFi. They test on that version. They demo on that version. And they ship that version to users who will never experience it the way it was designed.
This post is about a different way of working. Not performance optimisation as a checklist item at the end of a sprint, but performance as a design constraint that shapes every decision from the beginning. The distinction matters because one produces a fast version of a slow product and the other produces a product that was never slow to begin with.
Performance optimisation at the end of a sprint produces a fast version of a slow product. Performance-first design produces a product that was never slow to begin with.
WHY THIS IS NOT JUST AN EMERGING MARKETS PROBLEM
The instinct, when this topic comes up, is to frame it as a developing world problem. Slow connections are something you design for when your users are in low-income countries or rural areas. Once you have cracked those markets, you can go back to building the way you normally build.
That framing is wrong in two directions.
First, slow connections are not geographically contained. A commuter on the London Underground loses signal every few minutes. A conference attendee in San Francisco is on congested WiFi shared with three thousand other people. A remote worker in rural Germany has infrastructure that would be familiar to someone in rural Kenya. Connectivity is unreliable everywhere, for everyone, regularly.
Second, and more importantly, the design discipline that slow connections demand produces better products for fast connections too. When you are forced to think carefully about what information a user needs at each moment, you stop loading things they did not ask for. When you design for intermittent connectivity, you build interfaces that communicate state clearly rather than assuming the network will always respond immediately. When you treat every byte as a decision, you end up with products that are faster, cleaner, and more focused than products built without that constraint.
Performance-first design is not a concession to difficult conditions. It is a higher standard of product thinking that benefits every user on every connection.
THE CONSTRAINT YOU ARE NOT DESIGNING AROUND
Most UI decisions are made under an invisible assumption: that the network is reliable, fast, and free. That assumption is baked into default component behaviour, into how state is managed, into what gets loaded on page initialisation, and into how feedback is communicated to the user.
When you make that assumption explicit, you start to see how many decisions it is driving.
A page that fetches five API calls on load made the assumption that all five will resolve quickly and the user will not see a partially rendered state.
A button that disables after a tap and shows no other feedback made the assumption that the response will come back fast enough that the user will not question whether their action registered.
An image carousel that loads all images upfront made the assumption that the bandwidth cost of images the user may never scroll to is acceptable.
A form that only validates on submission made the assumption that the round trip to the server is cheap enough to use as a feedback mechanism.
None of these are bad decisions in isolation. They are all reasonable defaults under the fast-network assumption. The problem is that the assumption is false for a significant portion of users, and the experience degrades badly when it is violated.
Performance-first design means making the network assumption explicit and then designing as if it will not hold.
WHAT CHANGES WHEN YOU DESIGN FOR THE CONSTRAINT
You prioritise content over completeness
The first question in a performance-first design process is not: what does this page need to show? It is: what does this page need to show first?
The distinction is significant. Every piece of content on a page has a cost, measured in bytes transferred, render time, and API calls made. When you treat all content as equally urgent, you end up loading everything at once and the user sees nothing until everything is ready.
When you prioritise content, you load the thing the user came for as fast as possible and everything else follows. The article text before the comments. The product details before the recommendations. The critical action before the supporting information. The user can engage with something real while the rest of the page assembles around them.
This is not a performance trick. It is a design decision about what matters most on each screen, which is a question worth answering regardless of connection speed.
You design loading states as first-class experiences
On a fast connection, loading states are invisible. They resolve in milliseconds and the user never consciously registers them. This leads most teams to treat them as an afterthought: a spinner, a grey box, a blank space where content will eventually appear.
On a slow connection, loading states are the experience. A user on a congested mobile network might spend more time looking at your loading state than at your actual content. If that state communicates nothing meaningful, if it gives no sense of progress, no indication of what is coming, no confidence that the action registered, the user loses trust in the product before they have seen what it can do.
Skeleton screens, progressive loading, optimistic UI updates, and meaningful progress indicators are not polish. They are the product, for a significant portion of your users, on a significant portion of their sessions. Designing them with the same care as the content they precede is not extra work. It is the work.
On a slow connection, loading states are not a transition. They are the experience. Design them accordingly.
You treat every network request as a decision
A performance-first mindset asks, before every API call: does this need to happen now? Does it need to happen at all? Can the result be cached? Can the request be deferred until the user signals intent?
These questions sound like engineering questions but they are design questions first. The decision to load related content on page initialisation rather than on user interaction is a design decision. The decision to prefetch the next page of results before the user reaches the bottom of a list is a design decision. The decision to cache user preferences locally rather than fetching them on every session is a design decision.
When designers and engineers ask these questions together, before anything is built, the answers shape the architecture in ways that cannot be easily retrofitted later. A product that was designed around thoughtful network usage is fundamentally different from a product that was optimised for network usage after the fact.
You communicate state explicitly
One of the most damaging patterns on slow connections is the silent interface. The user taps a button. Nothing visible happens. The request is in flight but the UI gives no indication. After two seconds the user taps again. Now the request fires twice. Or they navigate away, assuming the action failed, and it completes in the background without their knowledge.
Explicit state communication is the antidote. Every action a user takes should produce an immediate visible response, even if the underlying operation has not completed. A button that changes appearance on tap. A form that shows a processing state before the server responds. An interaction that confirms receipt before it confirms success.
This is basic feedback design, and it is well understood in theory. In practice it is frequently skipped because it adds complexity and because it is invisible on fast connections where the server responds before the user notices its absence. Slow connections make the absence visible, which is why designing for slow connections produces interfaces that communicate more honestly with every user.
THE TEST YOU SHOULD BE RUNNING
The single most useful thing a product team can do to internalise this discipline is to test their product under throttled network conditions before every significant release.
Most browsers provide network throttling in their developer tools. A simulated slow 3G connection reveals things that no amount of fast-network testing will surface. Interactions that feel instant become obviously broken. Loading states that were invisible become central. Content priority decisions that seemed theoretical become urgent.
This is not a one-time audit. It is a regular practice that changes how teams make decisions, because the decisions look different when you can see their consequences on a realistic connection.
If your product has never been tested on a throttled connection, test it today. What you find will be uncomfortable. It will also be clarifying.
A HIGHER STANDARD FOR EVERYONE
There is a version of your product that loads on a slow connection and still feels considered, still communicates clearly, still respects the user's time and bandwidth. Building that version does not require a separate slow-connection mode or a stripped-down fallback experience. It requires designing the main experience with the constraint in mind from the beginning.
The users who benefit most visibly are the ones on the slowest connections. But the discipline that produces a product those users can trust produces a product that every user trusts more, because it communicates honestly, loads purposefully, and never treats the network as an assumption.
That is not a compromise. That is a better product.
CLOSING THOUGHT
Performance is not a feature. It is a form of respect for the person on the other side of the screen. When you design for the hardest conditions first, you are not lowering your standards. You are raising them in a direction that most products never bother to look.