The success of the Web performance movement shows that there is increasing interest and value in fast websites. That faster websites lead to more revenue and reduced costs is a well proven fact today. So being exceptionally fast is becoming the dogma for developing web applications. But what is exceptionally fast and how hard is it to build a top performing web site?

Defining exceptionally fast

First we have to define what exceptionally fast really means. Certainly it means faster than just meeting user expectations. So we have to look at user expectations first. A great source for which response times people expect from software is this book. It provides really good insight into time perception in software. I can highly recommend it to any anybody who works in the performance space.

There is no single value that defines which performance users expect. It depends on the type of user interaction and ranges from 0.1 seconds to five seconds. In order to ensure smooth continuous interaction with the user an application is expected respond within two to four seconds. So ideally an application responds within two seconds.

This research is also backed up by studies done by Forrester asking people about their expectations regarding web site response times. The survey shows that while users in 2006 accepted up to four seconds they expected a site to load within two seconds in 2009.

It seems like two seconds is the magic number for a web site to load. As we want to be exceptionally fast this means that our pages have to load in less than two seconds to exceed user expectations.

How much faster do we have to be?

From a purely technical perspective everything faster than two seconds should be considered exceptionally. This is however not the case for human users. As we are not clocks our time perception is not that precise. We are not able to discriminate time differences that are only a couple of milliseconds.

As a general rule we can say that humans are able to perceive time differences of about 20 percent. This “20 percent rule” means that we have to be at least 20 percent faster to ensure that users notice the difference. For delivering exceptional performance this means a page has to load in 1.6 seconds or faster to be perceived exceptionally fast.

How much time do we have?

At first sight 1.6 seconds seems to be a lot of processing time for responding to a request. This would be true if this time was under our control. Unfortunately this is not the case. As a rule of thumb about 80 percent of this time cannot or can only be indirectly controlled by us.

Let’s take a look at where we lose the time closely. A good way to understand where we lose the time is the Web Application Delivery Chain. It shows all the parts that play together to deliver a web page and thus influence response times.

Web Application Delivery Chain
Web Application Delivery Chain

On the client side we have to consider rendering, parsing and executing JavaScript. Then there is the whole Internet infrastructure required to deliver content to the user. Then there is our server infrastructure and also the infrastructure of all third party content providers (like ads, tracking services, social widgets) we have on our page.

Sending our initial request

The first thing we have to do is to send the initial request. Let us investigate how much time we are losing here. To be able to send the request to the proper server the browser has to look up the domain’s IP address via DNS.

Interactions for initial Web request
Interactions for initial Web request

Whenever we communicate over the Internet we have to take two factors into account – bandwidth and latency. Thinking of the internet as pipe bandwidth is the diameter and latency is the length. So while bandwidth helps us to send more data at each single point in time, latency tells us how long it takes to send each piece of data. For the initial page request we are therefore more interested in latency as it directly reflects the delay from a user request to the response.

So what should we expect latency wise. A study of the Yahoo development blog has shown that latency varies between 160 and over 400 milliseconds depending on the connection type. So even if we assume a pretty fast connection we have to consider about 300 ms for the two roundtrips. This means we now have 1.3 seconds left.

Getting the content

So far we haven’t downloaded any content yet. How big a site actually is, is not that easy to say. We can however use stats of the HTTP archive. Let’s assume we have a very small page of about 200 kB. Using a 1.5 Mbit connection it will take about a second to download all the content. This means we now have only 300 ms seconds left. Up to now we have lost about 80 percent of our overall time.

Client Side Processing

Next we have to consider client side processing. Depending on the complexity of the web page this can be quite significant. We have seen cases where this might take up to several seconds. Let’s for now assume you are not doing anything really complex. Our own tests at SpeedoftheWeb.org show that 300 ms is a good estimate for client side processing time.

This however means that have no more time left for server side processing. This means that in case we have to do any processing on the server delivering an exceptionally fast web site is close to impossible or we have to apply a lot of optimization to reach this ambitious goal.

Conclusion

Delivering exceptional performance is hard, really hard, considering the entire infrastructure in place to deliver content to the user. It is nothing you can simply build later. A survey by Gomez testing a large number of sites shows that most pages miss the goal of delivering exceptional performance across all browsers.

Performance across 200 Web sites
Performance across 200 Web sites

Faster browsers help but are no silver bullets for exceptional performance. Many sites even miss to deliver expected user performance. While sites do better when we look at perceived render time – also called above-the fold time, they still cannot deliver exceptional performance.