27

Possible Duplicate:
What is the shortest perceivable application response delay?

I've been profiling some JavaScript UI code because it feels a little laggy. So far, I've found some bottlenecks and optimized them out, but I'd like to define a measurable requirement for this.

How quickly should a response occur in order for a human not to notice lag? For example, what's the minimum detectable delay between when a keyboard key is pressed and when a letter appears on the screen? At what point is further optimization not going to make any difference to a human?

A lot of monitors have a refresh rate at about in the 60-120Hz range. Does that mean the magic number is around 8-16ms?

Community
  • 1
  • 1
pepsi
  • 6,785
  • 6
  • 42
  • 74
  • this is a very interesting question. I'm sure it varies but there must be some extremely good research in this area. – Preet Sangha Jul 30 '11 at 03:12
  • for 'instant' feedback - i remember testing the fastest human response time - at around 10ms – Randy Jul 30 '11 at 03:18
  • also i recall that the eye can process something like 25 frames per second in video. – Randy Jul 30 '11 at 03:19
  • 1
    There's a difference between minimum framerate for smooth animation, and maximum delay for a response to appear "instant". – hammar Jul 30 '11 at 03:21
  • clearly yes - but trying to optimize to faster than 1/25 sec is probably a waste :) – Randy Jul 30 '11 at 03:22
  • @Randy It's ~12fps. I'm sure 1/12 of a second won't make much difference to a user... depends on what you're doing, of course. – Mateen Ulhaq Jul 30 '11 at 03:28
  • If you want to test, try my [little example](http://jsfiddle.net/yafjf/20/). – Blender Jul 30 '11 at 03:43

4 Answers4

11

As a general rule, I find that anything quicker than 100ms tends to be perceived as "instant". Go much longer than that and the delay definitely becomes noticeable. Of course this will vary a bit from person to person, and also depending upon the context in which the delay is occurring.

You may find this example helpful: http://jsfiddle.net/QGmBy/

aroth
  • 54,026
  • 20
  • 135
  • 176
  • Nice example, but I'm pretty sure I can still see a delay for the 80ms one. Can anyone else? Though it's a popular answer, for some reason 100ms just seems too long to be the minimum detectable delay.. – pepsi Jul 30 '11 at 04:10
  • 3
    @pepsi In the field of usability the rule of thumb is that 0.1s is perceived as "instant", 1s as "pretty quick" and 10s as "getting bored and looking for something else to do". But these are ballpark numbers, not exact, and meant to represent the delays that start to interfere with the task at hand, not the minimum detectable. Yes, I can (only just) detect the 80ms delay, but I wouldn't call it "annoyingly slow" :) – j-g-faustus Jul 30 '11 at 10:07
  • @pepsi - What j-g-faustus said. The 100 ms is a general rule, not an exact answer. And yes, I too can tell that the 80 ms example is taking ever so slightly longer than the previous examples, but it still happens pretty damn fast. It's certainly much less noticeable than the 160 ms example. – aroth Jul 30 '11 at 12:26
  • Please not that while a 100ms delay is perceived instantaneous, a 50ms delay is perceived more instantaneous – Finesse Apr 19 '20 at 07:37
11

Considering the "press key" event and the letter appearing on the screen as two separate frames, means that, if the user presses a key while looking at the screen, he will want to see it exactly afterwards. This "exactly afterwards" means it should have a 60 Hz response time or higher.

For this reason, a 8-16 ms value should indeed be aimed for, since it will result in the same effect one sees in movies. In other words, the user will have no perception of delay for such values.

However, you must keep in mind that the keyboard has a polling time of its own, and that additional delays not necessarily connected with the script itself may interfere in its time. For those reasons aiming for values higher than 60 Hz will give you a bigger safety margin against those other possible influences that may add a minor delay.

Also of notice is the fact that in some applications, a delay of 100 ms might seem unnoticeable, but it is in fact noticeable since it corresponds to 10 Hz, and if you would play a movie at that refresh rate, you would most likely realize the gaps between each of the movie's frames. For this reason, this value should not really be considered in a generic enough context.

The human eye's sensitivity is different for different conditions and portions of an image, so you should be careful and consider higher refresh rates as necessary, to accommodate this.

This link has further information about how the screen characteristics and their changes are perceived by the human eye, and may give you an idea of which refresh rates you should aim for in a given context, based on the visual impact of your script.

Luis Miguel Serrano
  • 5,029
  • 2
  • 41
  • 41
  • 1
    But a human being cannot perceive the boundary between one frame at 60 Hz and the next. Particularly if only a small portion of the screen is being updated. Moreover, even if processing is done in time for the update to appear in the "next" frame, it cannot be guaranteed that that frame will actually be displayed immediately after the one the user currently sees. There may, for instance, be buffering being done by the graphics driver, or internally within the display itself (or both). Aiming for completion by the next frame is overkill in most cases (exception: games). – aroth Jul 30 '11 at 03:37
  • 1
    Still, it is possible that the script works with more than just one character, and I guess the most generic approach would be to look at it as a movie, in which from one frame to the next, the whole screen may change in multiple ways. Of course that in many cases it would not be necessary to be this drastic, but this was a bit of a mathematical approach. Even in games, a delay of 100 ms might be felt quite differently according to the game type, because of the implications of the delay and how we perceive them for the game in question. – Luis Miguel Serrano Jul 30 '11 at 03:49
3

I heard of a rule of thumb that 100 ms is fast enough. I'll try to find a link...

Edit: What is the shortest perceivable application response delay?

Community
  • 1
  • 1
Lenar Hoyt
  • 5,971
  • 6
  • 49
  • 59
2

If the event is occuring just once then 100ms should be the higher limit. if the event is a part of a continious movement, then something about 10-15ms should be it because a 100 ms delay in something like sliding stuff (a [one or more] pixel a time) can be noticeable if such delays occour in a row following each other.

Also it somewhat depends on the context, what is being delayed. a key press event, something sliding in, a realtime event happening on some other machine, all of these will have different 'tolerances' levels :)

Achshar
  • 5,153
  • 8
  • 40
  • 70