"Well, let's say you can shave 10 seconds off of the boot time. Multiply that by five million users and thats 50 million seconds, every single day. Over a year, that's probably dozens of lifetimes. So if you make it boot ten seconds faster, you've saved a dozen lives. That's really worth it, don't you think?"
- Steve Jobs
Clearly, there is a correlation between user interface response speed and the perceived usability of a site or app. But what does "response time" mean in a world of mobile applications, mash-ups, single page applications, and ajax?
For decades, the response times outlined by Jakob Nielsen (referencing a much earlier article) have been a baseline for how user experience professionals think about the response time of an application. These guidelines are a great starting point for thinking about usability, but applications have evolved and we need a new approach to thinking about response time.
In Google Chrome, there is a developer tool called the Timeline (IE has an identical tool in their F12 Developer Tools under the Network tab) that shows details of what occurs when any page loads. Using profiling tools, we can see the web page and its dependent parts, such as images, styles, and ajax calls, all load at different times. Each request to the remote server has several parts:
- Request start time
- Time it takes for that request to be sent and received by the remote server
- Time before the request gets an initial response from the server
- Duration of time between the beginning of the response and the end of the response
If a page must load from a remote server, and that page contains ten images, then we see graphically that there is a period of time spent loading the initial HTML, then new requests back to the server (or perhaps a CDN), one request per image. The images each take more than 0 milliseconds to return from the server, and they load later.
When usability professionals or developers think about response time, we often think about the time it takes to render a screen. With dynamic pages, the concept of screen becomes completely fluid, and this frame of reference is no longer appropriate.
Take Google Image search for example. When you search for any word, you perceive a collection of results being loaded immediately. However, using the Chrome Timeline feature, we can see that the page's initial load time is not the whole story. The images and page results load in about 3 seconds, then some ajax scripts load later clocking in at almost 8 seconds. Since I'm searching for images, seeing those early is a good user experience.
If I scroll down after everything loads in my image search, suddenly more network activity begins and more images are loaded into view. As I continue to scroll, the timeline and the list of items being loaded continues to grow in my Timeline.
The way to design around response time in a networked application should not necessarily be related to the page load time. Instead, focus on specific user experience paths:
- Relevance: Is this page relevant to me? Your response time should be oriented around answering this question quickly for a user. Other details of a page or screen can load later, but a user navigating to a new view of an application should be able to quickly see if what they are viewing is relevant. In the Google Image Search example, this means showing a small collection to the user quickly so the user can decide whether it is necessary to refine their search terms. In the case of a drop down menu, it means showing the contents of the menu quickly to allow the user to determine if this menu is the correct one to look inside. Think about times you have looked around in your computer for the correct Control Panel setting. Optimize for the scenario of at-a-glance decision about overall relevance.
- Context: How can this view or screen support my goals as a user? Optimizing response time to provide the user quick orientation for the sections and structure of a view, page, or screen will help support the perception of speed. Give the user orienting cues about the structure of your page early so those first milliseconds can help guide them to discovering how best to achieve their goals.
- Bailout: Optimize any loading page to allow the most clear bailout path in the event that this turns out not to be where the user should be.
- Best Next Action: Optimize any loading page to direct the user to the next best action. This may be choosing from a list of links to navigate somewhere, or it might be three buttons that capture a decision. One aspect of this that is in the direct control of developers is setting the cursor focus, for example defaulting the cursor to be focused in a text box, or defaulting the "Enter" key to click a particular button.
- Priority: For any given page, separate elements by user goal priority. The highest priority items should load first, the lowest last.
As networked applications become the norm, it will become important for us to make more clear distinction about what we mean about response times.