This post is a follow-up to “The Speed of Light and Human Expectations”, in which we identified some factors that impact the time it takes to load a typical web page.

Two of those factors were latency from the client to the content servers and latency associated with DNS.  Various techniques have been implemented to reduce both these latency figures in practice.

Today, most things viewed online are served off a content delivery network (CDN), such as Akamai and Limelight Networks. These companies position content servers as close as possible to the ‘subscriber edge’ of the network (as close to your house as is possible), so that subscribers get a low-latency, high-bandwidth experience when consuming content served by the CDN’s customers.  This is generally a win-win-win-win scenario, with consumers getting better quality of experience, Internet providers experiencing lower transit (and happier customers), content owners delivering increased reliability, and the CDN provider getting paid.

Most CDN providers use tricks with DNS to optimize the experience for the end subscriber.  One such trick is geo-targeting, in which the same hosts (for example, Facebook) will resolve to different IP addresses depending upon the origin of the look-up.  In other words, a subscriber in a particular city will get a different IP address for Facebook than a subscriber in another, even if the cities are relatively close together.

Now, what happens if you override your DNS settings so that instead of relying on your Internet provider’s DNS servers, you actually direct all your queries to a global service (for example, OpenDNS or Google Public DNS)? You might buy into the message of “better caching equals better DNS performance”, even though you know that the latency to these public servers is much greater than the latency to your ISP’s server.  But did you know that you’ve just broken the CDN model?

You can easily test the difference. Resolving Facebook via a public DNS server returns a particular IP address (for example, 72.246.43.8), which a ping test tells us is 40ms away.  Now, using my Internet provider’s DNS server returns 67.69.247.135, which is only 7ms away.

While the extra 33ms might not sound like a lot, when it’s added to each round-trip and considered in light of all the serial and parallel TCP connections required to load a typical web page nowadays, then we’ve suddenly added a full second to the page load time (and we’ve already seen that the difference between a 2 second load time and a 3 second load time is the difference between a happy Internet user and a user who closes the web page in disgust).

Join in for the final part in this series next week, “Measuring the Quality of the Internet”