What's the minimum lag detectable by a human?

Question

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?

Solution 1

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.

Solution 2

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/

Solution 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?

Solution 4

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 :)

View more solutions

Comments

[Preet Sangha]

this is a very interesting question. I'm sure it varies but there must be some extremely good research in this area.

[Randy]

for 'instant' feedback - i remember testing the fastest human response time - at around 10ms

[Randy]

also i recall that the eye can process something like 25 frames per second in video.

[hammar]

There's a difference between minimum framerate for smooth animation, and maximum delay for a response to appear "instant".

[Randy]

clearly yes - but trying to optimize to faster than 1/25 sec is probably a waste :)

[Mateen Ulhaq]

@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.

[Blender]

If you want to test, try my little example.

[aroth]

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).

[Luis Miguel Serrano]

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.

[pepsi]

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..

[j-g-faustus]

@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" :)

[aroth]

@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.

[Finesse]

Please not that while a 100ms delay is perceived instantaneous, a 50ms delay is perceived more instantaneous