I am involved with the development of a Windows application that has various screens. One of them takes ten seconds to appear with no spinner or other indication that the screen is loading. I consider this a serious performance issue but I seem to be the only one who is concerned.

Am I being overzealous? What is an acceptable amount of time to wait for a screen to appear?

  • 2
    Is that 10 seconds on a developer's top of the range machine, or 10 seconds on the average user's seen-better-days machine?
    – MZB
    Jul 8, 2011 at 18:33
  • @MZB: 10 seconds on developer's machine...
    – blue
    Jul 8, 2011 at 18:48
  • @8kb what is the issue that is causing the screen to take so long to appear. Jul 8, 2011 at 21:28
  • 3
    Android will consider a screen stuck after 5 seconds, if I remember well. Then it will ask the user if he wants to kill the application or keep on waiting. Jul 8, 2011 at 21:52

7 Answers 7


This is old research but 10 seconds is bad:


from the page:

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.

  • 1
    Never leave a user wondering if they just broke the software, even a small reminder window that pops up immediately with a predicted time to completion stops end-user anxiety and leaves them feeling in control. Jul 8, 2011 at 21:55
  • 4
    I'd argue the timing data is outdated, seeing it was written about 20 years ago. Today, with incredibly powerful machine on every desktop and proliferation of real-time interaction, people are accustomed to much shorter response times than 10 seconds. Jul 8, 2011 at 22:01
  • 2
    I agree that 10 seconds is way too long for a screen to appear without any feedback. For anything that takes longer than ~2 seconds I would probably put (at least) a spinning wheel to show that the program is doing something, if not a progress bar.
    – DMan
    Jul 8, 2011 at 23:18
  • 1
    The data is concerned with a person's thought processes. As such it probably isn't that outdated. However, 10 seconds without feedback is far too long these days. There are techniques to improve perceived responsiveness.
    – BillThor
    Jul 9, 2011 at 13:15

More than two seconds without an hour-glass and I'm already pretty skeptical. Different people will have some different expectations but I would expect 10 seconds with no feedback to even acknowledge that I clicked a button or whatever would annoy almost anyone. Whether or not it matters to annoy your users is another question.

  • Agreed - you should pop up a "wait cursor" or some other indication very quickly. Based on UX norms, I'd rather see it in something like 0.1 to 0.25 second rather than two seconds.
    – Bob Murphy
    Jul 8, 2011 at 22:10

What do the intended users of this application think? If they're OK with it, then don't worry. Some applications that have to process lots of data, it's OK for a window-open command to have a bit of a delay before opening.

If it's possible to add a splash screen or a progress bar or something to indicate to the user that it's working that would be good. I usually try to add a progress indicator of some sort if my testing shows that a window regurlarly takes more than 2-4 seconds to appear.


We stick by a rule that it should take no more then 2 seconds for ANY feedback to appear for the user.

I said any feedback because there are times when it is not possible to load up the entire page within 2 seconds. You have to let users know what to expect after first 2 seconds.


Although DKnight cites good research in his answer, another thing to consider would be the performance requirements of the system. Are the users doing some kind of time-sensitive work or for some reason need quick requirements? If you can somehow ask the users what response times they would like to see, especially in terms of minimally acceptable times, that would be best. Performing usability testing with observation would also be good for overall usability, and if you see a user getting frustration with waiting after performing a specific action, then you know to revisit the performance of that portion of the system.

In terms of generalities, though, I would suspect that 10 seconds is indeed a long time. There are some long-running operations, and if this is indeed the case, it is important to provide cues to the user that the system is still working and to continue waiting.


I agree that 10 seconds are definitively too much. I worked for intranet applications in a Software House (used only internally by employees) and maximum delay while loading a page was 5 seconds. This was for me the limit.

However I saw other internal application, very complex indeed, but where loading time was something dramatic. In the worst situation, due to thousends of records/queries executed it took around 2 minutes! But this is of course too far away from the general context.

Therefore I would conclude saying that 3 or 4 seconds are the limit for providing a good response service.


This is not a performance issue as such, but a GUI issue. The user should be TOLD what the program does and if it takes longer than 1-2 seconds, a progress bar should be displayed.

That said, there might be a REASON for this, if it used to be fast, but that is not what you asked.

The typical problem with such applications is running out of physical memory so Disk I/O becomes the bottleneck for loading and swapping. It might also simply be that the datasets have grown so big that the O(N^3) algorithm now shines through.

  • I think that a progress bar should only be used if the duration or total tasks is known. Otherwise, something more indeterminate should be used.
    – Thomas Owens
    Jul 8, 2011 at 22:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.