« How do you respond to your customers' requests? | Main | How late is “late” to keep a customer loyal? »

November 18, 2008

What is “typical” for web response time?

Very often I participate in discussions where web response times are discussed and I hear all kind of strange statements (called “crap”:)). While browsing the Web for the last 13 and so years, starting with slow (9.6Kbps) modem connection over analog telephone line and ending with quite satisfying (6Mbps) broadband one I can certainly say that I’ve build my own opinion. When I hear statement “typical page load time is 6 sec” I get really pissed off. I want to scream: “Are you nuts?!!!! 6 sec is ridicules time! Who is going to wait 6 seconds for your crappy page to load?”

I remember few years ago at SAP when we developed one of the first WebDynpro application and our prototype page loaded in… (hold on)… 20 mins. And I remember the time before SAP when colleagues of mine developed online PDF merger that presented the success page with link to the merged PDF after… (hold on again)… 20 mins (I don’t know what is so “typical” about the number 20 but they really responded after approximately 20 mins of time). Twenty minutes is totally unacceptable response time for any application (not only Web) and this examples triggered research I did years ago (SAP one is from 2003 and the PDF one from 2001) to understand what are the acceptable response times in Web space. After searching Google for the PDF scenario and reading the UX guidelines for the WebDynpro one, the number 3 stuck in my mind and I can’t get it out now.

3 seconds is the response time you should not exceed on the Web! That’s it!

Searching in Google today here is one of the top results you will receive The Psychology of Web Performance. I really like the following sentence from the post:

“Keep your page load times below tolerable attention thresholds, and users will experience less frustration (Ceaparu et al. 2004), lower blood pressure (Scheirer et al. 2002), deeper flow states (Novak, Hoffman, and Yung 2000), higher conversion rates (Akamai 2007), and lower bailout rates (Nielsen 2000).”

10 years ago when the modems ruled the world the goal was to create small pages that can be served fast via modem connection. Today we create huge pages that contains tons of images, videos, style sheets, JavaScripts, Flash and who knows what else. Some of these can exceed few hundred kilobytes. However users don’t care how big the pages are; they don’t care how many images there are on the page; they don’t care how many servers are in your web farm. Most of the users don’t understand the mechanics behind the page, and why should they? The only thing they care about is how fast your page is loaded via their 6Mbps broadband connection.

Here is my table for tolerable response times on the Web. It is based on the post above as well as on Response Times: The Three Important Limits.

Response Time Analysis
<0.1 sec I don’t think you can achieve this one on the Web (if you can, the the user’s browser will not be able to render it:)) but it is goal that you may want to pursue.
<1 sec Your page load time is great. You can continue to improve your performance but only if you don’t have better things to do.
<3 sec Your page load time is OK, however you need to keep an eye on it. You are on the border for broadband users. However if this is the load time over narrowband you should not be worrying too much.
<4 sec This is the limit for broadband users. I certainly think you have a problem if your users need 4 secs to load your pages and I will suggest you spend some time improving your performance.
<6 sec You are on the border for narrowband users. Performance should be one of the things you should be thinking already.
>6 sec You are amateur:) Your web site may still be visited but you will lose visitors (approx. half of them including myself). If you don’t care keep going.

Few more things that you need to think about when you exceed the 1 sec threshold. The first one is that you need to provide feedback showing the user you are still working on the request. Modern browsers do provide progress bar although it is not useful all the times because it spins like the hourglass in Windows without giving you any indication when the result will appear. If you go above the 6 seconds threshold you must think of ways to change the workflow or even the architecture (we managed to solve the 20 mins issues above only through major changes in the architecture).

Although performance is not the only key it is one of the keys for your web site’s success. If you target the thresholds in your performance testing you will surely be screwed because you don’t account for the unknowns and you will surely exceed the threshold. What happens next – the user moves on.


Feed You can follow this conversation by subscribing to the comment feed for this post.

Post a comment

Comments are moderated, and will not appear on this weblog until the author has approved them.

If you have a TypeKey or TypePad account, please Sign In