Acceptable waiting time for users in time sensitive actions

Question

Is there an acceptable waiting time for users when they are on banking or finance related websites after they perform an action? I expect that for important tasks users are prepared to be more patient, but if it is a bidding or auction related website then they would want to know that the transaction is immediate.

Probably the ‘gold’ standard when it comes to general website performance in relation to user behaviour: http://www.nngroup.com/articles/powers-of-10-time-scales-in-ux/

• 0.1 second 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. Feedback during the delay is especially important if the response time is likely to be highly variable, since users will then not know what to expect.

The closet I can find to an industry standard benchmark is the Compuware APM Benchmarks http://www.compuware.com/en_us/application-performance-management/Benchmarks/view-benchmarks.html

The closest I can find to any actual figures are from the Best of the Web 2013 awards handed out by Compuware, which specializes in website performance benchmarking. The average response time for the winners in the brokerage category that uses a Generate Order Transaction ( includes accessing the home page, logging in, navigating to the trade page, selecting a stock, previewing the order, cancelling the order, navigating to the trade page and logging out) are:

• response time: between 3-4 secs
• average availability: 99.9%
• standard deviation: between 1.5-2.2 sec

These are the figures from the server side, and usually there is about an extra second or two added to the response time in getting to the actual user device (the so-called 'last mile'). So basically all of the transactions on the websites that are regarded to be the best performing that industry are well within the 10sec barrier but a little bit more than the ideal 1sec response time. However, depending on the particular action of the user a 3sec response time would be more than acceptable.

Does anyone have experience or know of any standard measures for these types of response times?

UPDATE: The RAILs model published by Google provides another set of standard for user interaction response time, but is based on similar principles and ideas.

Answer 1

I don't think there is tbh. It always depends on the context, and users generally want everything at once.

This UX Stack answer is related but doesn't quite answer your question. It contains the guidelines from J. Nielsen but I don't see how they can apply without having a user context. Also, nowadays, who has the patience to wait even close to 10 seconds for something.

A fair amount of the answers are about giving the user good feedback on what's going on, which would have been my answer as well.

A simple load animation is suitable for processes that are short and are unlikely to fail, while a progress bar that actually represents the progress, preferably also telling in text what the status is, is better for longer processes (users should be pretty experienced with loading spinners that keep on spinning even though the page is frozen).

While good system response and clever animations might improve the perceived performance, one should always strive to make one's product as fast as possible. Countless articles treat this subject, for instance this golden oldie from Google.

When your site is running at top speed, there is of course the option to make it slower again if it suits the flow on your site, but the true performance needs to be there.

Answer 2

Jeff Atwood blogged about this in a post called Performance is a Feature.

We've always put a heavy emphasis on performance at Stack Overflow and Stack Exchange. Not just because we're performance wonks (guilty!), but because we think speed is a competitive advantage. There's plenty of experimental data proving that the slower your website loads and displays, the less people will use it.

[Google found that] the page with 10 results took 0.4 seconds to generate. The page with 30 results took 0.9 seconds. Half a second delay caused a 20% drop in traffic. Half a second delay killed user satisfaction.

In A/B tests, [Amazon] tried delaying the page in increments of 100 milliseconds and found that even very small delays would result in substantial and costly drops in revenue.

That link leads to another post:

Maybe I'm just impatient. However, there's a lot of concrete data to support the theory that unless you make it load fast, nobody will stick around long enough to find out what you have to offer. For instance, a recent study found that most shoppers will only wait four seconds for a page to load before abandoning the site entirely.

Dare also cited this post by Greg Linden which provides more quantitative data on page load times from Google and Amazon:

Google VP Marissa Mayer just spoke at the Web 2.0 Conference and offered tidbits on what Google has learned about speed, the user experience, and user satisfaction. Marissa started with a story about a user test they did. They asked a group of Google searchers how many search results they wanted to see. Users asked for more, more than the ten results Google normally shows. More is more, they said. So Marissa ran an experiment where Google increased the number of search results to thirty. Traffic and revenue from Google searchers in the experimental group dropped by 20%.

Ouch. Why? Why, when users had asked for this, did they seem to hate it?

After a bit of looking, Marissa explained that they found an uncontrolled variable. The page with 10 results took .4 seconds to generate. The page with 30 results took .9 seconds. Half a second delay caused a 20% drop in traffic. Half a second delay killed user satisfaction.

This conclusion may be surprising -- people notice a half second delay? -- but we had a similar experience at Amazon.com. In A/B tests, we tried delaying the page in increments of 100 milliseconds and found that even very small delays would result in substantial and costly drops in revenue.

So, it appears that computer users are indeed impatient, and behaviour is extremely time-sensitive. The major difference between a search engine and a banking site is that the banking site has a captive audience. Even if your users are unlikely to flee to a competitor over an extra one second of response time, they'll be secretly cursing your slow website, wishing it were faster.