User Experience Stack Exchange is a question and answer site for user experience researchers and experts. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

The title basically says it all. The question is not too easy to google:

What is the maximum time I can block the UI thread without creating a noticeable 'lag' in the UI from the user's perspective?

share|improve this question

migrated from Jul 25 '13 at 11:42

This question came from our site for professional programmers interested in conceptual questions about software development.

I don't think you should block the UI thread at all but less than 100ms. – Michael Jul 25 '13 at 10:12
With 'blocking' I mean, keeping it busy, which implies loading controls, etc., so stuff the UI thread is responsible for. 100ms seems reasonable... – Marc Jul 25 '13 at 10:17
suspect this is a better fit for ux.stackexchange – jk. Jul 25 '13 at 10:39
I seem to remember my usability professor telling us the lower limit for human perception as related to pointer input was 20 ms or so. – Max Jul 25 '13 at 10:59
Your title is asking about tolerable time, and the body is asking about noticeable time. What one were you after? 2 seconds might be noticeable, but may be very tolerable on a mobile device for example. – Brendon Jul 25 '13 at 14:46
up vote 23 down vote accepted

The really short answer is 100ms.

This number comes from the article Response times - The Three Important Limits by Jakob Nielsen, which contains an excerpt from his book Usability Engineering.

Mr. Nielsen is a recognized authority on UI design, and does a tremendous amount of analytical research related to UI design.

The article and book give these numbers:

  • 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 article provides citations for the basis of those numbers. In a later blog post titled Powers of 10: Time Scales in User Experience he expands on this topic.

share|improve this answer
Perfect, thanks!! – Marc Jul 25 '13 at 11:02
Great links. Thanks. – dbasnett Jul 25 '13 at 12:35

It depends on what the application is doing and on what your users are used to.

For a desktop application users are used to not having a responsive UI during startup or potentially file open for a variety of applications. but during other tasks, e.g. typing, even very small pauses will cause negative experiences.

There does appear to be a human limit of about 0.1s at which we perceive things to be more or less instantaneous, so, as some commenters have mentioned, always responding within 0.1s is certainly one way to meet user expectations (it might be technically hard to meet this however)

share|improve this answer
Thanks, thats the answer I was hoping to get. – Marc Jul 25 '13 at 10:56

Microsoft WinRT api is designed such that a method taking longer than 50 milliseconds is an async method. This can be taken as a guideline for responsive apps.

share|improve this answer
Thanks, thats a good anchor.. – Marc Jul 25 '13 at 10:57

As expressed in other answers, the 100 ms response time is a good limit. It is a good limit for desktop applications, but we already know that for certain applications this time might be too slow.

For console games for example the "input lag" of the TV is often considered to be bad when exceeding 30-40 ms. So here the expected responsiveness must be better than 100 ms to have a good product. So it also depends on the domain where the application is used in.

share|improve this answer
The GUI thread gets blocked in every existing software, because it is there to do something (load controls, handle user input, etc.). I could have rephrased the question: How long can an operation on the UI thread take without having a noticeable lag. Thanks for your answer, all in all it seems that the timespan I was asking for is somewhere between 30-100ms and that was exactlxy what I wanted to know. Thanks! – Marc Jul 25 '13 at 11:01
Thanks for the comment, I wanted to express that from a technical perspective this should be the goal to minimize the time it gets blocked. I will rephrase that. – malte Jul 25 '13 at 11:03

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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