Alois Reitbauer About the Author

Why you have less than a second to deliver exceptional performance

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 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.


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.



About The Author
Alois Reitbauer
Alois Reitbauer


  1. I have been experimenting with load times for a long time.
    Recently we have used an architecture, where the ENTIRE website is on googles CDN at The only thing the backend does is deliver data as json strings, through jsonp calls.
    This has the added benefit that we are essentially creating an API at the same time as we are developing the site. Furthermore, we can host all the static files on a completely different infrastructure and domain than the database and API.

    For database we have chosen the nosql database MongoDB, it is exceptinally fast.
    For webserver we have chosen Node.JS, it is also exceptinally fast.

    Chosing these technologies means that we hav ONE programming language in our entire stack: JavaScript. Furthermore our API implementation is very lean, there is no need for an ORM of any kind, and our data is represented as json, a subset of JavaScript.

    It is really wonderfull to work with and our website and webapplication is exceptionally fast.

    We measure the time for API calls on the client, the actual time including network transport, and the response times are on average 200 milliseconds for simple api calls, and 500 ms for complex api calls that return around 200 KB of data.

  2. Kiran Kumar says:

    Exceptional blog, Thanks for sharing. This is an eye opener for all those who as obsessed with performance. No doubt, performance is key to deliver rich user experience at the same time designer should not loose focus on other important aspects of a successful website/application.

  3. Although dynatrace it’s an exceptional tool i honestly belive there is a bit hype about speed. Too much panic. For instance if the second it’s so important how come dynatrace is not doing so great on his own tests ?

    Really 50% of the problem is what you find AFTER the page loads. I seriously doubt any sane person would ditch yahoo mail or ebay because one second delay.

    Let’s take some time to breathe.

  4. Hi Detolu,

    I think speed is important. If you really need to reach response times of 1.6 seconds is another story. I wanted to point out how hard it is to be really fast. I used arguments like this to convince managers that they have to invest real resources in web performance and it is nothing that you can simply turn on. This helped to get form “just make it faster in your lunch break” to “ok we have to set this up properly to work”

    Service quality is also always important. However if I have two equal services I would always choose the faster one. Don’t you think so? The main idea behind SpeedoftheWeb was to show people what is standard in their industry and this very often is not 1.6 seconds.

    Concerning our own web sites I agree that they should be faster. We always push to make them faster but also do not always get optimal performance. Should we do better? Sure, we should. At the same time our core business does not depend on any of these sites. If it would the story would be a different story.

    // Alois

Speak Your Mind


Do the math so we know you are human *