As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 7 years ago.

For a complex web application that includes dynamic content and personalization, what is a good response time from the server (so excluding network latency and browser rendering time)? I'm thinking about sites like Facebook, Amazon, MyYahoo, etc. A related question is what is a good response time for a backend service?

For a site such as Facebook, they have a 1.8-2 second time to first byte / which includes a good chunk of content on page. Then they ajax the rest of the content in the next 1-2 seconds.
– MKN Web SolutionsFeb 7 '14 at 17:59

The basic advice regarding response times has been about the same for thirty years [Miller 1968; Card et al. 1991]:

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.

@KarthikCherukuri - yes, it's still relevant. The answer is talking about human perception, which is a function of biology. The time between 1993 and today is pretty small when it comes to evolutionary time scales. Our neuroanatomy is the same now as it was then.
– rianjsDec 3 '17 at 15:57

We strive for response times of 20 milliseconds, while some complex pages take up to 100 milliseconds. For the most complex pages, we break the page down into smaller pieces, and use the progressive display pattern to load each section. This way, some portions load quickly, even if the page takes 1 to 2 seconds to load, keeping the user engaged while the rest of the page is loading.

Maybe he really meant 20 milliseconds. The app I'm presently working on has typical response times averaging around 15 ms (when testing locally on my laptop). That's not what most users actually see, unfortunately, since they're far away from the server, plus there's render time you have to include, too. But from a pure app perspective, 15, or even a tad under 10, is very possible, even for a complex e-commerce app.
– AquarelleJul 12 '14 at 5:49

That's fair. My question is a bit general. I guess I am looking for real world numbers of what people are striving for. A know a lot of it depends on the situation. Thanks!
– Michael BobickOct 2 '08 at 19:48

Our company has a 5 second response time standard limit, and we aim for 2-3 seconds in general. This accounts for 98% of page loads. A few particular tasks are allowed to go up to 15 seconds, but we then mitigate that time by putting up a page and refreshing every 5 seconds telling the user that we are still trying to process the request. That way the user sees that something is happening and doesn't just leave. Although, considering that I work on a website whose users are forced to use for business reasons, they aren't going to leave, but they are capable of complaining quite loudly.

In general, if the processing is going to take more than 5 seconds, put up a temporary page so that the user doesn't lose interest.