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?

  • I don't think you should block the UI thread at all but less than 100ms.
    – Michael
    Commented Jul 25, 2013 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
    Commented Jul 25, 2013 at 10:17
  • 3
    suspect this is a better fit for ux.stackexchange
    – jk.
    Commented Jul 25, 2013 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
    Commented Jul 25, 2013 at 10:59
  • 2
    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
    Commented Jul 25, 2013 at 14:46

5 Answers 5


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.

  • There are off by an entire order of magnitude. Commented May 23, 2023 at 13:04
  • @R..GitHubSTOPHELPINGICE: why do you say that? Are you saying the number should be bigger or smaller? Do you have research to back up your statement? If so, you should add another answer to this question. Commented May 23, 2023 at 15:39
  • OK I added an answer. Commented May 23, 2023 at 18:25

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.


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)


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.

  • 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
    Commented Jul 25, 2013 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
    Commented Jul 25, 2013 at 11:03

The famous Nielsen numbers in the accepted answer are wrong. This is not a failing of the person who wrote the answer, but of the upstream source.

While I don't have data to establish good replacement numbers, I would say they're roughly off by an order of magnitude. In other words:

  • More than around 10ms of latency (one refresh period at 100 Hz; that would be 16 ms at 60 Hz) feels non-instantaneous and "input lagged". This is common knowledge to anyone who does any kind of action gaming, and I've seen but don't have saved references to papers that support this claim for touch screen interfaces too.

  • More than around 100ms of latency interrupts flow of interaction, enough to wonder if a click actually went through and produce repeated input events from user frustration.

  • More than 1s of latency suggests the program is frozen unless it's doing something to actively indicate otherwise.

Again, these aren't exact numbers, but closer to reality than the widely cited ones, which seem to have been used to launder the UX performance regressions of the 90s and beyond.

From a purely anecdotal standpoint, I stand behind the above figures 100%. To me, an interface with more than one refresh period of latency is physically painful to use. Perhaps this just means I'm different, in the same way folks who find high-frequency pulsing of LEDs intended to be perceived as "solid on" physically painful are "different". UX that does not account for this is inaccessible and bad UX. Folks who write recommendations to do things that are inaccessible and exclusionary like this are committing harm.

  • 2
    Do you have reliable and reproducible research to back up your statement? All we read is "I don't have data", "I've seen but don't have saved references" which is quite weak compared to your strong statements in this general sense . Your arguments might be related to action gaming which is a special use case as malte pointed out. Commented May 23, 2023 at 18:57
  • 1
    I think the requirements for "action gaming" and for user interfaces are going to be vastly different. Commented May 23, 2023 at 18:59
  • Action gaming is a data point that shows that the latency is (1) very perceptible even to "normies" and (2) relevant to UX at least in some contexts. Commented May 23, 2023 at 19:19
  • 1
    You may have a point here, given that Nielsen's research is 30 years old (like saying Iron Age in Internet times). But without any objective research backing up your claim, the only thing we can read is your subjective experience. I'm quite sure you're on the right track, just provide any reliable reference
    – Devin
    Commented May 23, 2023 at 19:44
  • 1
    @Devin: Even at the time, slow UX was a regression. For historical context, this was the time GUIs were being introduced. Existing prior text-mode apps had intantaneous response to keystrokes. Commented May 23, 2023 at 19:47

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.