Physical distance

Where the client and the server are located has a great impact on the user experience. If they are close and the Internet connection is fast, a website can load even in 2 seconds, but if they are far and the packets have to move through many hops at slower speeds, the same site can loaded in 20 seconds. The slowdown factor can vary up to 10 times and maybe even more on a mobile device. For every resource we have, the physical distance needs to be travelled two times—one for the request and one for the response. With a large distance, only the DNS lookup can take a couple of seconds. The blog page on this site is said to load in 7 seconds from China, despite being fairly lightweight. Steve Souders has tested and found that it can take more than 30 seconds to load from the same location in China.

More web designers need to be aware of these differences and account for them from the start. What we think is a negligibly small JavaScript file can take 2 seconds to load from far, so this will be noticed. What we gain from speeding up site development through the use of frameworks shouldn't find expression in what the other side of the globe loses; we can't zero sum our work this way. And the user is always right.

Something else that is noticeable is that media files constantly grow bigger. It becomes harder for people on a low bandwidth to see something more than individual video frames. The larger the distance, the more noticeable the delay between where the user is and where he wants to be in a clip. If someone clicks on the timeline with the goal to see what happens ten seconds later and loading this exact frame takes ten seconds, the effect will be worse than if this person simply left the streaming to continue with a ten seconds of irrelevant material. Media files shouldn't be only usable at the place of streaming. A timeline is time-bound or otherwise unusable. What we can do is to intentionally encode videos for high and low bandwidth or provide a single version of the lowest satisfactory quality that keeps the message clear.

Site performance varies with the conditions of the environment and it is unrealistic to think that we can measure it precisely. What we develop locally presents a best-case scenario—one that allows us a relative comparison of the changes we make. This is what we can measure and it can be quite useful. But the performance of what is live is just a snapshot in time and the result depends on the number of simultaneous requests, physical distance, server load, network congestion and other factors, many of which are beyond our control. Gaining insights from metrics that vary too much can be very hard. We need to think of the worst-case scenario and prepare for it in advance.