Design for Users on the Other Side of the Planet

Systems & Architecture · latency, performance, internationalization

Updated 2026-08-04

Remember that distance is time and no amount of engineering removes it. A round trip across an ocean costs well over a hundred milliseconds before your server does any work, and every extra request pays it again.
Count round trips rather than optimizing payload size alone. Four sequential requests to a distant server cost more than one larger response, however well compressed the small ones are.
Test on a throttled, high-latency connection as a matter of routine. A local test answers in single-digit milliseconds and hides every interaction that depends on a fast reply.
Put static content close to the user and accept that dynamic content cannot always be. Images, fonts, and scripts can be served nearby, while a write to the primary database goes wherever that database lives.
Design the interactions that assume a fast reply out of the far-away case:

Make optimistic feedback the default for actions that almost always succeed. The interface can respond in zero milliseconds while the network takes three hundred.
Show the size of a slow region's problem before you argue about it. Latency numbers by country turn "it feels slow for some users" into a decision somebody can fund.
Keep the first meaningful paint independent of any distant call. A page that renders locally and fills in remotely is usable on every connection.

Your interface is fastest where you built it, and that is the one place its users mostly are not.