Users have certain expectations of products and services. If these expectations are met by some in the class, but not by others, then competitive forces reward the top performers. If the entire class fails to meet them, then the class fails or an innovator will subsequently disrupt the status quo.

With web pages, Internet users have an expectation that pages will load within a ‘reasonable’ amount of time. What is reasonable varies, but it is generally agreed that the sweet spot is somewhere under 3 seconds. A recent Akamai survey found that 47 percent of consumers expect a load time of less than 2 seconds. In fact, 40 percent of respondents indicated that they would leave a site if it takes longer than 3 seconds to load.

Consumers also have the expectation that increasing bandwidth must solve any Internet quality issues, but bandwidth is not the panacea that everyone thinks it is.

Consider that the load time for a web page is determined by a combination of:

• Bandwidth speed and the size of a page
• Latency of the network (between the client and DNS server, between the client and web server)
• Jitter of the network between the client and the server
• ‘Think time’ of the server and the client (memory access, Javascript execution, etc)

A typical Web 2.0 site has 10-20 unique TCP connections required to load all of the content (including cookies, spyware, advertisements, HTML-content, images, Javascript libraries, etc). Web browsers have tried to address this reality through the parallelization of connections. A well-designed site will have the HTML fetch first, which then has instructions for what else needs to be loaded subsequently and in parallel.

All things considered, and making the assumption that TCP instantly ramps up to the maximum speed of the Internet connection, then a typical Web 2.0 page will load in something like:

Load Time = (page size / bandwidth) + [number of DNS lookups * (client-to-DNS server latency + client-to-DNS server jitter)] + [number of serial TCP connections * (client-to-servers latency + client-to-servers jitter)]

In reality, TCP employs a congestion management algorithm called AIMD (additive increase, multiplicative decrease). One of the features of this algorithm is called ‘slow-start’, which causes TCP to linearly increase in speed until a packet is lost, at which point it slows down and hovers around that rate. If packets are lost due to congestion, then TCP cuts its rate in half each time. In the Web 2.0 world, AIMD means that the many small TCP connections required for each site never reach their full speed, allowing latency and jitter to dominate the Load Time calculation.

Of course, this is all very technical, and is a topic that is foreign to the vast majority of Internet subscribers. Consequently, when a subscriber upgrades the 2 Mbps connection to a spiffy new 100 Mbps package, instantaneous page loads might be an expected benefit. What will the subscriber think when there is no noticeable difference in page load times?

The conflicts between consumer expectation and technical reality pose a major challenge for the Internet providers of the world. These companies are spending billions of dollars on fibre and DOCSIS 3.0 technologies, but fixing latency is tougher than increasing bandwidth.

Reducing latency requires moving DNS and content servers down to the edge, removing segments of routing, and flattening the network. Ultimately, it requires increasing the speed of light , and that has proven difficult.

Stop by next week when I’ll talk about “DNS, CDNs and the User Experience”