Jakob Nielsen's Alertbox for March 1, 1997:

The Need for Speed

Every Web usability study I have conducted since 1994 has shown the same thing: users beg us to speed up page downloads. In the beginning, my reaction was along the lines of "let's just give them better design and they will be happy to wait for it". I have since become a reformed sinner since even my skull is not thick enough to withstand consistent user pleas year after year.

Research on a wide variety of hypertext systems has shown that users need response times of less than one second when moving from one page to another if they are to navigate freely through an information space. Traditional human factors research into response times also shows the need for response times faster than a second. For example, studies done at IBM in the 1970s and 1980s found that mainframe users were more productive when the time between hitting a function key and getting the requested screen was less than a second.

Unfortunately we are not getting subsecond response times on the Web any time soon, so we know that users are going to be hurt by slow downloads. Currently, the minimum goal for response times should therefore be to get pages to users in no more than ten seconds, since that's the limit of people's ability to keep their attention focused while waiting.

The figure shows the distribution of the speeds with which users have connected to the Internet according to the last six Georgia Tech Web user surveys. Two things are clear from the figure: users are replacing slow modems (14.4) with fast modems (28.8 or 33.6), but the proportion of users who connect at modem-speeds stays about the same. Even worse, the proportion of users connecting at high bandwidths (T-1 or better) is going down, even though the Web requires at least T-1 speed to work well. Mid-band (ISDN, leased lines, etc.) is increasing somewhat, but the truth is that mid-band speeds are insufficient for decent Web response times.

The problem is that the user's experienced response time is a determined by the weakest link in the chain from server to browser:

• the throughput of the server: ought not to be a problem since the cost of hardware is the smallest part of developing a website, but popular sites often get surprised by rapidly increasing traffic and do not upgrade their machines fast enough.
• the server's connection to the Internet: many sites try to save on their connection and put off upgrading from, say, a T-1 to a T-3 even when their current connection is saturated
• the Internet itself: even though the net keeps getting upgraded, it still has bottlenecks, especially for cross-continent connections and for use at peak hours
• the user's connection to the Internet: as discussed above, connection speeds are very low for the majority of users and will stay that way for several years
• the rendering speed of the user's browser and computer: rarely a big problem, though complex tables can take significant time to lay out on low-end machines

Each of these many steps introduces its own delay in getting a webpage from the server to the user. Unfortunately, the delays are cumulative, meaning that we are not going to get snappy response times simply by improving a single link in the chain: when you upgrade from a modem to an ISDN line, you typically get twice as good Web performance and not the five times improvement implied by the bitrates.

Considering these fundamental facts in both human factors and computer networking, there is only one conclusion: webpages have to be designed with speed in mind. In fact, speed must be the overriding design criterion. To keep page sizes small, graphics should be kept to a minimum and multimedia effects should only be used when they truly add to the user's understanding of the information.

Conservative use of graphics does not imply boring pages. Much can be done by colored table cells and creative (but restrained) use of different fonts. In particular, style sheets can be used to improve page design without incurring a download penalty. If you are using style sheets (and everybody should be doing so by the end of 1997), I do recommend making them linked rather than embedded: a linked style sheet only needs to be downloaded once (assuming that you have a consistent style for your site), whereas embedded styles add to the size of every single page.

The most important issue in response time is when the user gets to see a screenful of useful information. It matters less if it takes longer to load the full page and all its illustrations if the user can start acting on some information fast. Guidelines for fast initial loading are:

• the top of the page should be meaningful even when no images have been downloaded (i.e., more text, less images)
• use ALT attributes for images so that the user can understand what they are about before they are rendered
• the browser must draw the top of the page fast: it can only do so if it has all the information it will need for layout, so include WIDTH and HEIGHT attributes on all images and table columns
• complex tables often take a long time to render, so cut down on the complexity of your tables by splitting the information into several tables. In particular, the top table should be simple and fast to render.

A practical tip: links to a directory should include the final slash in the URL when embedded in webpages. The slash should be left out when writing the URL for human consumption. For example, the link to the list of Alertbox columns should be written as http://www.useit.com/alertbox in a (printed) magazine article but coded as http://www.useit.com/alertbox/ for the hypertext anchor in the online version of the article. The reason to include the slash in online links is to avoid a redirect when the server would have told the browser that the link refers to a directory and not a file. Adding trailing slashes to HREFs when appropriate reduces latency by a small but noticable amount, so you may as well do it.

A final recommendation is to use a server that supports HTTP keep-alive: saving the overhead of establishing a new TCP/IP connection for every "hit" cuts latency dramatically. The experienced response time to load a page often drops to about half by using keep-alive.

Update August 2000: Internet Still Slow

So what else is new?

The ICONOCAST newsletter for August 17, 2000 reported the following distribution of Internet subscribers in the United States:

• Dial-up connections (i.e., at most 56.6 kbps): 93% of home users
• High-Speed connections (DSL, cable modem, etc.): 7% of home users

The growth in users during the second quarter of 2000 was:

• Dial-up: 14.5 million new subscribers
• High-speed: 0.7 million new subscribers

Update January 2004: Still Mostly Slow

Nielsen//NetRatings (no relation, and I don't endorse their methods, but it's probably still a reasonable approximation) reported that 38% of home users were on "broadband" (mainly cable modem or DSL) as of January 8, 2004. In other words, 62% were still on dial-up.

In Europe, the estimate from IDC was that 26% of home users were on broadband in December 2003. (In other words 3/4 of users on slow connections.) In Asia, you can find a few small countries with high broadband penetration, but across all of Asia, the percentage is even smaller.

In 3.5 years, broadband penetration in the U.S. has increased from 7% to 38%, or about 9 percentage points per year.

Assuming the same uptake speed in the future, we will get full broadband penetration in 7 years, or 2011. (Of course, it's likely that the diffusion rate will decrease once the people who are really motivated have upgraded. There are a lot of people in remote locations who are going to be hard to wire.)

We probably won't get to 100%, but we could reach 90% broadband by 2011.

Current "broadband" rates are not true high-speed connections, running mostly around 1 Mbps. Ten times that speed is the minimum for many services, and you could argue that we need fast Ethernet speeds (100 Mbps) for some scenarios. (Of course, I want even more speed for the ultimate user interface.)

Some people will start getting truly fast connections in the home around 2010, and then we will start the upgrade race all over again, with most people being on "slow" cable modems and some people being on fast fiber. This again means that there will continue to be a need to differentiate services between connection speeds until at least 2025.

More on Responsiveness

Related full-day courses at my User Experience 2008 conference in Chicago and Amsterdam:

• Fundamental Guidelines for Web Usability, about responsiveness for websites
• Application Usability 1: Page-Level Building Blocks for Feature Design, about progress indicators and other ways to handle slowness at the page level
• Application Usability 2: Dialogue and Workflow Design, about flow in applications; how to make apps feel responsive