In a world of instant gratification: What response time goals should be set, and how will we achieve them?
The early years
It was only a few years ago when site designers wanted to get their websites to load under 10 seconds, and load testing was only used to verify if it will crash or not. However, this was in the HTML 1.0 days when client-side code didn’t exist, nor did the smartphone, and simple sites ran on much slower servers compared to what we have today.
What we knew before the dawn of time
Stepping back even earlier, user experience professionals in 1968 identified three time limits determined by human perceptual abilities. And while our perceptual abilities have not improved, our expectations have. These three levels have been published numerous times and articulated in Jakob Nielsen’s book, “Usability Engineering” from 1993 (essentially pre-Web). As he states about computer responses:
0.1 seconds is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.
1.0 second is about the limit for the user’s flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data.
10 seconds is about the limit for keeping the user’s attention focused on the dialogue. For longer delays, users will want to perform other tasks while waiting for the computer to finish, so they should be given feedback indicating when the computer expects to be done.
We began to learn
More than a decade later, in the 2000s, people began focusing on website (home page) load speeds. The correlation between the speed of a website and loss of customers had been shown concretely. Yahoo found that a 400ms improvement to the speed of its home page increased their pageviews by 9%. Firefox shaved 2.2 seconds off the average page load time and increased download conversions by 15.4%. Shopzilla reduced its site’s load time from 7 seconds to 2, and increased its page views by 25% and revenue by 7%-12%.
Today’s reality
This brings us to today. One Google experiment designed to look at response times increased the number of search results per page from 10 to 30, with a corresponding increase in page load times from 400ms to 900ms. This resulted in a 25% drop-off in first result page searches. And simply adding the checkout icon (a shopping cart) to search results made responses 2% slower (adding 8ms) with a corresponding 2% drop in searches per user. Similar results are now appearing with the use of mobile apps and users expecting near-instantaneous response rates.
Users have become used to sub-second response times—not just on a home page, but across the usage of a site or mobile app, at all steps and all requests. This has been driven by a relentless long-term effort at leaders like Google, Amazon, Facebook and others. Their goal is to deliver against any request as close to 100ms as possible, which means it’s essentially instantaneous to the user. While they have not achieved that goal quite yet—certainly not on average—they continue to close in on those targets.
(IMPROVE APPLICATION TESTING BY 20x)
By focusing on the actual user experience, not just the server response, those companies can tune server code and architecture as well as client-side code to deliver rapid response rates. In doing so, they have started to effectively condition the world to believe that instantaneous response is a reasonable expectation to any request. If Google can search the world’s largest database and return results in a few hundred milliseconds, and Amazon can search the world’s largest store and do nearly the same, why would anyone believe that it’s acceptable to deliver results to a query in 6 seconds and be proud of that? There are now hundreds of apps and sites that regularly deliver pages or responses in under 500ms. Does yours?
The bar has been set at 100ms
One second is too long for several reasons. First, users have been conditioned to faster response times from world-class providers. Second, at one second, the user has lost his/her train of thought, which is the one thing you don’t want a user to do. At one second, you lose 7% of your users and see a 16% decrease in customer satisfaction metrics. That’s at one-second responses at every page, and we’ve known this for almost 50 years.
However, if the largest players can drive toward 100ms, so can anyone. Their methods have required full beginning-to-end performance validation (UX through back end) at every build (true agile), and a set of goals to continue to bring the transaction times down at every release (which of course can occur hourly or daily). In this way, nothing gets added to the code or architecture that could encumber the long-term goal of instantaneous response. Moreover, every day is an exercise in driving down transaction times as a matter of cultish behavior.
Where we go from here
Google analytics tracks website and mobile app speeds at the UX, and it has released the averages for 2013. Desktop sites and app page speeds were around 2.5 seconds (median) and mobile around 3.2 seconds (median). These show we have a long way to go to get to 100ms, but that isn’t an impossible goal. It increases user retention, revenue and brand loyalty. It should be a C-suite imperative, and it gives a lot of smart developers and QA teams plenty to work on in the coming year. Here’s to recognition and great progress!
