The Perception of Speed

December 3, 2012 5:02 pm | 19 Comments

Have you ever noticed that when you click on a link the page doesn’t change right away?

If I had written the code I would have cleared the page as soon as the link was clicked. But in a masterstroke of creating the perception of faster websites, browsers instead don’t erase the old page until the next page arrives.

Keeping the old page in place improves the user experience for the same reason that making airline passengers walk six times longer to get their bags reduces complaints about long waits at the baggage claim. “Occupied time (walking to baggage claim) feels shorter than unoccupied time (standing at the carousel),” according to M.I.T. operations researcher Richard Larson, an expert on queueing. In my example of clicking a link, occupied  time (looking at the old page) feels shorter than unoccupied time (staring at a blank screen).

Let’s try an example using this page you’re currently viewing. Both of the following links add a five second delay to this page. The first link refetches this page the normal way – the browser leaves the old page until the new page arrives. The second link clears the page before refetching. Which feels slower to you?

Clicking the first link leaves the user staring at this page’s text for 5+ seconds before it refreshes. It’s slow, but not that noticeable. Clicking the second link makes the same wait time more annoying. I actually start getting antsy, shuffling my feet and shifting in my chair. For real users and web pages this translates into higher abandonment rates.

One takeaway from this is to keep your eye on the ball. In the case of web performance, we want to create a faster, better user experience. There are great techniques for tackling that problem head-on (reduce repaints, optimize JavaScript, etc.), but sometimes you can make significant improvements with changes that address the user’s perception of speed such as spinners and progress bars.

Another takeaway is to build single page web apps. The old Web 1.0 way of requesting a new page for every user action and repainting the entire page is more likely to produce a jarring, slow experience. Using Ajax allows us to keep the user engaged while requests and responses are handled in the background, often being able to do them asynchronously.


19 Responses to The Perception of Speed

  1. Very cool test and set of observations. However…

    I just showed this to my wife (a non-techy but heavy internet user)… she said “the second one seems faster because at least it looks like it’s doing something when it clears the screen.”

    So… there may be some selection bias in this test if the results are that only techies agree with you. ;-)

  2. One problem with leaving the existing page in place is that if the new page is not very different, you don’t notice it has loaded and keep staring, waiting, even though it has actually loaded.

  3. I preferred the second link. I was looking for the content to reappear instead of scanning the browser status bar.

  4. Both links feels slow to me.

    Yes, in first case I can continue reading/scanning the page that I’m leaving, but most often, I suppose, it’s not much of use (we’re leaving it, right?)

    It would be slightly better if you add loading indicator in your first case or if you flush unstyled or partly loaded page in second case. That is a standard approach for heavy UI with huge loading times.

    It it absolutely obligatory to show user current status, either it is ‘loading …’ indicator or gradually loaded page.

  5. In my personal website and blog, I wanted to have a nicer ux when moving between pages, so i added transitions in/out – in when the pages has been loaded (also fonts are being loaded as well) and out – after i click a link.
    It gives a nice fade transition and contributes to the overall ux when navigating in the website and out of it as well.

  6. Interestingly, Safari 6 on Mac provides the same experience for both links (it does not clear the screen on the latter).

  7. Hi Steve!
    I’ve made something that users can keep their eyes on :)
    Can be funny or only just a cosy spinner…

  8. Cliff & Steve: Normally clicking links would take you to different pages. You have a good point, but it’s more an effect of this particular test (of refetching the same page).

    Oren: I totally agree with your idea of code to manage the transition between pages. I encourage other people to take a look at your site.

    Eric: There are differences between browsers that I’ll blog about later, but the Safari difference is likely due to a race condition in how I implemented the clearing code, and not an intentional choice in Safari.

  9. You make a good point, Steve. Actuality is not the experience, it’s what is perceived that is the experience. Gabor Zsoter’s occupied.js is a great example of how the perception can be completely changed by just a small visual distraction.

    Thanks for the lesson.

  10. There’s one subtle point not mentioned here– navigations to resources that return HTTP/204 or HTTP/205 responses don’t unload the current page. The only way to know when such a response is forthcoming is to actually issue the request and wait for at least the status line of the response.

    PS: Your spam blocker thingy results in the user’s entire post getting wiped out when they click “back.” It would be nice to at least move the box above Submit Comment, if you don’t want to call AutoCompleteSaveForm to ensure that its contents aren’t lost.

  11. Hi Steve,

    Here are a few things that I’ve noticed when researching this topic for boomerang (with some help from Eric Goldsmith)…

    Current browsers fire the onbeforeunload event when the user initiates a departure from the current page (eg, by clicking a link). They fire the onunload, when the page is being cleared out of the viewport. Interestingly, the onunload event fires 1ms after the first byte of the new response arrives (this is true even for non-navtiming browsers).

    Safari 6 is interesting. It fires onunload when the page is removed from memory and not when it is removed from the viewport. It fires the pagehide event when removing a page from the viewport. It turns out that pagehide on Safari 6 is the same as onunload on other browsers.

    Lastly is the interesting case of Opera. In all browsers except for Opera, downloading a resource in onunload will not block. The browser will send the request, but not wait for a response. Opera, however, will not start downloading the new page until it has finished downloading all resources that were downloaded as part of the onunload event. This is bad news for sites that fire a beacon in the onunload event.

    Hope you can take this research further.

  12. How about a hybrid of the two versions where the link highlights immediately to give feedback that the browser has detected the click then the page changes only when the new page is ready to display.

    This gives immediate feedback to the user while allowing them to continue reading the existing page, while waiting for the new page to be ready to display.

  13. For me as well, the second link actually feels faster because the instant I click it something immediately happens. Now, it would be even nicer, I suppose, if there were a spinner on that completely blank page to let me know that something is still happening, but for the first link I actually had to look around—up at the location bar—to make sure that I had actually successfully clicked the link. That’s no good. If I have to search around for some indication that I successfully initiated some action I’m much more likely to keep trying that action in vain, get frustrated, and leave.

  14. I like the theory behind this, but in the real world does it work? I would assume not, because of the current perception / experience people have when clicking a link… As ever, everything is worth a test on a ‘per-site’ basis, then after looking at the stats, make an informed decision.

    Nice for an article to spark some thought and actual theory instead of ‘web designers skillset’ style post that is a basic article generated to hit certain keywords and link build.

    Nice work.

  15. That’s really cool, Oren…how did you accomplish it?

  16. One interesting approach that seems to have been used my is to provide a momentary flash on initial page load. I have’t been able to replicate this today. But when I went to the site during the first few weeks of their RWD unveiling, it seemed there would be a momentary hiccup that let me know something was taking place. Then the page would download. I am not sure if it was a technical issue or what. But now that I think of it, it seems they were using sort of version 2 for initial download, but some type of progress indicator to show the page was being downloaded. Note that this only occurred during initial page download.

  17. Since the first year that web browsing was offered, I’ve witnessed exponential growth in technology and geometric increase in computational speed among consumer products. The apparent increase in web browsing speed has only been linear. Part of that has to do with the additional bells and whistles taking up computational cycles and the lack of optimization. The best programs (whether client or server based) always have some type of status update while loading each section and for the overall process. If the time to complete server-side operations are in proportion to the amount of data or complexity of request then it may be better to break those into smaller steps. To maintain a steady pace, at any given time the page enages the user in reading, watching, typing and clicking something. The number of steps may increase but the smaller periods of inactivity are less noticeable than a long period of activity followed by a long period of inactivity. Your web statistics are immensely useful when finding where your site bogs down. You can use that information to code your loading bars to show an increasing rate of progress. The user feels they are arriving to the next page faster.

  18. Walmart is using an interesting approach for the mobile experience. When the user clicks a link, the System displays a modal window with a progress indicator until the user reaches the destination page. I like this idea since I sometimes never know what’s going on with the page load and the visual indicator is good to know. Wondering if anyone else has seen this implemented on mobile.

  19. Very cool experiment. Indeed, the first version seems faster, however, it makes me feel like nothing is happening and makes me feel more anxious than the second version, which seems slower but, in a way, more natural.