From the Nielsen Norman Group, an article about creating an “efficient” experience. [Original Link]


The typical web experience is a series of slow, stuttering steps, punctuated by moments of utter boredom. We can do better, and we can do it without faster processors, servers, or networks. How? By taking advantage of subjective time.

Time: Objective vs. Subjective

Objective time can be accurately measured with a stopwatch. “It took 3 minutes and 4.78 seconds for the water to boil.” Subjective time is different. We humans are notoriously poor at judging time. Sadly, pleasurable experiences slip by quickly while dull or disphoric experiences drag on forever. A classic example lies in our universal subjective impression that water-heating time is attention-dependent: “A watched pot never boils.” Why? Because watching a pot is a boring experience. Instead, our parents taught us to avoid this phenomenon by carrying out a parallel activity, one that will engage our minds so that the time passes by quickly. (One effective strategy I was taught in boyhood was to spend the time not thinking about elephants.)

(We do have a “loophole” in our inability to judge the passage of time. We are quite good with the very short intervals found in music, and one can develop a fairly accurate internal “stopwatch” by humming a favorite song and noting how long a particular passage takes. Humming the same song at a later date will take very close to the same time.)

Our subjective inaccuracy has different causes. For one, time simply appears to speed up when we are engaged and slow down when we are disengaged. For another, we suffer amnesia during the time it takes to make a decision, even a little one, such as what cursor key to press next. This decision interval is equivalent to the time it takes to find a mouse, leading people to believe that cursor keys are faster because their subjective experience is faster, even though stopwatch studies, including my own, consistently find cursor keys about half as fast as the mouse.

The Web: A setup for slowness

We’re all aware that the web is slow. It will remain so for the foreseeable future. The problem is that we haven’t gotten where we want to go, which is HDTV-plus resolution for video, full-bandwidth audio, and lots and lots of high-bandwidth multimedia. Every time average speeds increase, websites will continue to suck up the extra speed by increasing the media density of their sites.

If the average speed of a page load is not going to increase any time soon, what can we do to make the web a bit more pleasant? We can alter subjective time.

JetBlue vs. American Airlines

JetBlue is a company that understands subjective time. American Airlines is not.

The American Way

Consider a cross-country flight on American. You arrive at the airport two hours early. You open up your laptop to find they want $6.50 to let you log into the network. Two hours for $6.50 is the equivalent of $2,340.00 per month. Kind of steep. You instead decide to read the leftover paper lying on the table. Of course, the original owner took all but the Real Estate section with him.


You get aboard the flight and strap into a seat from the famous Spanish designer, Torquemada. For the next hour there’s nothing to do but buy overpriced products you’ll never use, or, alternatively, you can read up on “The Wombat Problem in Perth” in the airline’s own hip, slick and cool magazine. Then the “entertainment” starts: Thinly-disguised video press-releases featuring MBAs pushing services, punctuated with more traditional commercials.


Finally, we get to the movie which is either something you don’t want to see or something you really, really do want to see, but not on a lousy faded 15 inch screen twelve feet away while listening to sound reminiscent of a crystal radio. I guess it’s time to read up on that Atomic-Powered Nose Hair Clipper again.


They then show that episode of “I Love Lucy” that everyone so much enjoyed back in the early 1800s followed by…nothing! We’ll be landing in a hour or so, so it’s time to shut off the entertainment system completely.


A six-hour flight on American feels like a 12 hour flight.

JetBlue Cool

JetBlue, on the other hand, welcomes you to their pre-flight lounge with free Internet access. Settle down and do the exact same thing you would if you were hanging out in your living room. Transfer to the plane and sink into a business-class-style leather seat in economy, slip on your headphones, and you are connected to the world via DirectTV. You have 40 “live” channels on your personal screen, and those channels are typically on from the time you climb into your seat until the time you climb out at your destination.

It’s a funny thing about 40 channels. It takes about a half-hour to really check them out. Even if “there’s nothing on,” it’s now the next half hour, time to work through them all again—an engaging experience.

A six-hour JetBlue fight feels like a 3 hour flight.

(Yes, yes, I know. JetBlue has been known, in bad weather, to hang out on the tarmac for several hours before actually taking off, but so have all the others, and I’d rather be out there with 40 channels of live TV than being treated to a bonus episode of “I Love Lucy.”)

Speeding up Subjective Time on Websites

A lot of the suggestions I offer in my “Websites that Sell” course (see below) result in reducing both subjective and objective time, but I want to concentrate on the three most important here, with emphasis on the last:

First, do an analysis of your site and find out where people are spending their time. Then, consider whether they really want to be there. No one, for example, wants to be on the checkout page. It’s just not fun. No one except the designer and his mom want to be on the splash screen, watching Flash laboriously drawing a content-free image. It’s just not fun. Streamline the checkout page and dump the splash screen.

Next, time-test subjects performing tasks using a stopwatch and then, at the end of the task, ask the subjects to estimate how long they took. (Of course, don’t have a big, giant clock sitting in front of them during the test.) Boring tasks will be those reported as taking a long time; engaging tasks will have seemed to be over in mere moments.

Finally, specifically look for “boredom points,” places where users are sitting around, twiddling their thumbs, just waiting for something to happen. These almost always occur when the user decides to move to a new page. At this point, all life stops as we wait and wait for the new-page pot to boil. Why is this point inherently boring? Because, once the users click Next, their work is done. They’ve made their decision and they’re now mentally stuck in traffic, waiting for the next step to appear. During that waiting time, there is typically nothing task-oriented for the user to do.

Programmers, in their personal lives, have long faced this problem when launching a compile and have learned to cope through such off-task activities as reading comic books and playing FreeCell. Users can’t do that because they have no way to predict the wildly varying wait times that different pages and differing Internet conditions produce. Instead, they just sit there and stare at the pot.

For years, our weapons to attack boredom points have been rather crude. We can reduce objective time by making the new page’s file size smaller, so that it doesn’t take two minutes to load. We can reduce subjective time by giving the user something to think about or something to do while waiting: “You’ll need your credit card number for the next page.” Kind of lame, I know. Some have tried fetching a smaller page to keep people entertained while they’re waiting for the big page. It’s an interesting strategy of extending objective time, because of the extra page fetch, to reduce the experience of subjective time. It’s proven an unfortunate, if somewhat effective solution, but it’s still on the lame side, and that’s the problem. Chipping away at these boredom points has been really hard.

Eliminating Boredom Points

We finally have technology that can reduce or eliminate many boredom points.

Consider the checkout flow: When a customer finishes Step 2 of the 4-step process, what’s she likely to do next? Um, maybe step 3? So why do we sit around on our hands doing absolutely nothing while waiting for her to click the next button? Because we’ve always had to.

Not any more.


We finally have the power to reduce or eliminate boredom points entirely. What miracle is this? A technique that has been around since the sixties, maybe even the fifties, but finally arrived on the web.

Prefetching allows you to fetch elements of the next page while the user is working with the current page. These elements are loaded in the background, ready to spring forth instantly when the user clicks Next.

One would think such a miracle would be instantly embraced by every webmaster on the planet. Suddenly, a website can feel as fast as a dedicated application! Suddenly, customers don’t have to wait and wait (and maybe go away) when they’ve asked to look at a specific product.

Here’s the problem: Webmasters freak out at the thought of your prefetching any content that may never be viewed. Sure, there’s a really good chance that someone on Page 2 of your order process is going to Page 3. But what about the customer looking at your page with 36 different electric toasters on it? Where’s he going to point? You can’t prefetch 36 different pages, all with 100k of graphics! It would bring the servers to their knees!

See what I mean about not having as much bandwidth as we want any time soon?

Fortunately, a solution exists.

First of all, some of the most critical pages, such as those in the checkout form sequence, are highly predictable, and few if any machine cycles will be “wasted” prefetching material not ultimately used.

Second, we don’t really have to fetch that much to eliminate our “boredom points.” The problem is not that it takes a long time for a webpage to finish loading, it’s that it takes a long time before it even begins to appear. People can start to read as soon as the first words appear. What we need to prefetch, typically, is the HTML and any ancillary code that controls the rendering of the HTML, thereby presenting the words right away so the customer will have something to do while waiting for the images. This requires being really disciplined about specifying image sizes, etc., so the page doesn’t jump around as subsequent elements arrive, a minimum quality standard for a site anyway.

You still don’t want to download even the text for 32 toasters, at least not until Internet2 rolls out with its 100x speed increase, but your log files will let you know which ones people are most often drawn to, and you can prefetch those.

How do you add prefetching? It requires only the simplest of HTML code. You’ll find the instructions on the Mozilla Link Prefetching FAQ page. This is not a Firefox-only solution: Prefetching also works with Internet Explorer under XP and Vista as long as Google Web Accelerator has been installed. (Someday, the old dinosaur may even prefetch on its own. Some day.)

Getting push-back from the engineers? Shoot them this nice write-up with Prefetching Hints put together by a fellow engineer. it not only tells how to do low-server-load prefetching, it has hints for closing a loophole that can already allow Firefox users, on their own, to start prefetching everything on your site, bringing your servers to their knees. Included also is a way to tell how much random uncontrolled prefetching is happening already. It may be that you can install a sensible prefetching strategy and actually gain back machine cycles by closing off the uncontrolled access. (Google, for its part, also further acts as a caching proxy, btw, reducing your server’s load.)

Changing Our Ways

To achieve instant page viewing will also require we change some of our practices. For example, today, when the user finishes Page 2 of checkout, we do server-side checks and then get back to her with the result, a task that is time-consuming in itself. That may be tradition, but there’s no reason we have to handle it that way since the subsequent pages in checkout do not typically depend on the content of the previous page. (A forgotten phone number will not effect the credit card number on the next page.) Instead, move the user directly to page 3 and wait until reaching the confirmation page to ask for corrections/additions. That will give the server time to do the checks in the background while the customer labors on.

Before any of these changes, however, first reduce the error rate by allowing, for example, people to type in phone numbers in a single field using whatever spacing and punctuation they personally find most comfortable. (A single, simple line of code can strip all the spaces and punctuation out later.) Probably half or more customer errors are prompted by hostile forms. These errors cause major hits on the servers by requiring multiple error scans as well as re-serving pages already sent.

You should also explore ways of making the pages themselves more dynamic to reduce the need for new page serves in the first place. Reader Todd Eddy reminded me of the power of AJAX to deliver pages with a user-experience more akin to a real application: “The server only needs to grab a small chunk of data that updates a single section.”

Into Action

Start small, reducing/eliminating the boredom points at which your customers are abandoning your site today. Ensure the checkout process, specifically, is as streamlined as possible. Review the log files with the engineers as you begin to add prefetches and find out how much of a “hit” the site is actually taking because of prefetching—probably less than imagined. Compare that with reduced drop-out rates at those points.

Slashing subjective time on your site by 50% is a perfectly reasonable goal. Indolent worker George Costanza once reflected on the time in the shower you wait for the hair conditioner to work as, “a really tough minute.” A minute waiting for hair conditioner to work while getting ready for a date can feel longer than the three subsequent hours you spend with that very special person. Reducing/eliminating boredom points can make the time spent on your website appear to really fly by.

The world is beginning to embrace prefetching. So are your competitors. It will take time for your company to ramp up. The time to begin is now.

A Reader Response

I completely agree with you on this, and as far as filling out forms goes, Ajax is the key. Here are some further things you can do for forms:

1. The blank form, when it comes up, already has, written below each field, a message stating what makes it unacceptable, e. g., “password must be at least six characters” or “e-mail address must have an @ sign in it”.

2. Whatever error checking can be done on the client side, is done there, via JavaScript. So as soon as you type the sixth character of the password, the message that it must be at least six characters vanishes. (All of these checks have to be done again on the server side, too, of course.)

3. Server side error-checking is done on a per field basis, using Ajax. So if you type in a user name that’s already taken, you’ll know about it as you’re filling out the next field, rather than only after submitting the form.

Curt Sampson

Tog Replies

I completely agree with you on this. On point one, I also recommend adding a suggested format following the label that precedes the field, for example, for US phone numbers:

Phone (111-111-1111)

However, do then accept any punctuation the user actually enters (including none). You may then strip their punctuation away and re-present the number in the above format. Re-presenting the number has two benefits. First, if they entered it without punctuation, as the web has trained them, it offers it back in a form far easier to scan for errors. Second, it tracks the human-to-human communication method of reflecting back what the speaker has said using slightly different words to ensure that the meaning, not just the string of words, has actually come across.