Are there any studies on whether one will actually get more done during a days work if delays went down i. e. from 10 ms to 5 ms for each update. My point is that if we are already working at the speed of thought, the GUI is not the bottleneck.

5 Answers 5


While not talking about response times as low as the question, there are some very interesting results from tests carried out by Google and Bing here:


The bottom line is that users interact more with responsive web pages and the companies made more profit. I would think it's not too fanciful to extrapolate these and say that faster response times are nearly always desirable. Of course the gains will get increasingly small and you will run into the limitations of hardware.

It's probably the case as James Crook answered that fast UI responses act to increase comfort with the interface and so increase productivity rather than the time savings themselves allowing more to be done.

  • So nice to see the first relevant study! Very interesting results! What it seems like is that delays will make users distracted an hence less productive. On the other hand, the user might actually have gotten distracted into doing something more productive than the search he was about to do. I set my example delays to only 5 ms, but I am very interested in the longer delays as well, like in the studies.
    – David
    Commented May 22, 2011 at 21:39
  • They are nice results and clearly set out. It's a great article to show to clients as it links page speed to profit which always gets they're attention.
    – edeverett
    Commented May 22, 2011 at 21:46

Hard Limits

In the 10ms-5ms range you're running into the refresh rates and response times of pixels on your monitor. Many monitors are limited to 60Hz (17ms refresh). You're also getting close to limits of visual perception. We take around 100ms to direct our eyes to something new that has appeared on screen.


The difference between a compile taking 10 seconds and 0.5 seconds is very noticeable, and very demonstrably affects productivity. A change from 100ms to 50ms for a screen refresh makes a perceptible difference, but it is of a different kind. We're talking about how pleasant to use the system is rather than how fast it is. Just as most people think better in a noise-free environment (music is another topic), so too high resolution, smoothly moving flicker free images are less disruptive to thought than 10fps refresh rates and jerky scrolling and zooming.


If you want to test for whether a 100ms to 50ms change makes a difference, you're not testing whether the saved 50ms delay is saving you 50ms. You're testing whether the more comfortable environment is making people more productive. It's a different kind of test to a 10s to 5s test. You have to pay more attention to things that might make the environment less comfortable, like fan noise, flickering fluorescent and nearby conversations - they become relatively more important. At 10ms to 5ms you have to take that controlling of the environment to the next level - and you need to buy that 240fps monitor otherwise you'll see no change at all.

  • Screen refresh rates are conceptually like traffic lights. One could argue that if the cycle of a traffic light is every minute, then it would not matter if one arrives 5 seconds earlier, but this argument is obviously wrong.
    – David
    Commented May 22, 2011 at 15:17
  • One can get used to response times of one hour (I have tried this with SQL queries). This did not disturb my thought process. I think the thought process is only affected before one gets used to something. This also goes for flickering and jerky scrolling as long as it is predictable.
    – David
    Commented May 22, 2011 at 15:22
  • 5
    @David the user can get "used to" long response times when they're doing repetitive tasks. If they're doing non-repetitive, creative tasks (e.g. programming), then anything above a ~2s delay is interrupting the flow to some extent. On the other hand, below some threshold (e.g. 0.1s), it becomes a matter of comfort, not efficiency (on par with having a decent office chair -- it helps but does not directly affect productivity if two equally motivated users).
    – dbkk
    Commented May 22, 2011 at 19:59
  • @dbkk I would think that it is the direct opposite. People doing repetitive tasks will tolerate less delay, then knowledge workers as the knowledge workers will have lots of thinks to think about during the delays.
    – David
    Commented May 22, 2011 at 21:16
  • 3
    @David: people doing repetitive task often get into a rhythm, the length of the delay simply dictactes the frequency of the rhythm. With repetitive task varying delays are more likely to break flow. Commented May 23, 2011 at 6:04

I learned, that in program usage, interaction delays below 0.2 s aren't recognised. A fast secretary makes 600 hits per minute, which is 10/s, most users won't reach 300/min or 5/s. A response faster than 0.2 s is felt as immediate response. You needn't be faster than that.

  • Isn't this assuming that one blinks the eyes every time one makes an interaction (which is very cute when done by novice computer users). If the response comes earlier, then the person can start processing the new information earlier (guess it would be stared by the eye searching for relevant areas on the screen). What I do not know is what kind of brain activity is going on at this moment. Does one have to post-process the interaction, which was just made?
    – David
    Commented May 22, 2011 at 15:14
  • 2
    Try to follow the numbers with your eyes: for n in {1..30}; do echo -n $n" "; sleep 0.20; done ; echo. How many GUI-changes does your user have? If you have 5 changes per minute, where you save 1/10 s from 0.2 to 0.1s per interaction, you save 30s per hour or 4 Minutes per working day, and only, if your user is using your program during the whole 8h with the constant speed of 5 actions per Minute. I have a program, where I fill out tests with radio buttons, spread over 6 pages, which lasts about 90s per questionaire. If you work on high speed, you rarely wait for feedback from the UI ... Commented May 22, 2011 at 15:50
  • ... but you push, push, push. Commented May 22, 2011 at 15:51
  • 1
    @user unknown: in certain applications, you might regularly work with dragging and dropping objects or scrolling the screen and in these sort of applications low frame rate will be perceived as jerkiness. While jerkiness itself might not affect our theoretical ability to interact with the software, the annoyance caused by the jerkiness might preoccupy the mind of the user such that it decreases productivity. Certainly while 200ms response is Ok for pushing buttons, it is probably way too slow for drag and drop.
    – Lie Ryan
    Commented May 22, 2011 at 17:55
  • Yes, when you draw lines and such, you need to do it faster. My impression was, that the question was about buttons, textfields, comboboxes and so on - not painting or ego shooter games. Commented May 22, 2011 at 18:16

It depends on when the savings occur. CPM-GOMS studies (http://www.rpi.edu/~grayw/grayres/ernestine.html) showed that expected gains in efficiency of a new system may not be realized because many tasks may rely on other outside activities that will negate the savings. If your taks is highly sequential, you will see the gains, if not, it is less likely to be beneficial.


You could always argue that being a slave to the machine doesn't actually help you 'get more done during' in a day's work.

There are higher levels of brain activity than those involved in managing a software interface.

Not having 'instant gratification' can sometimes be a good aid to having to sit down and think a bit more deeply about something.

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.