人类可检测到的最小延迟是多少？
可能的重复：
可感知的最短应用程序响应延迟是多少？
我已经一直在分析一些 JavaScript UI 代码，因为感觉有点滞后。到目前为止，我已经发现了一些瓶颈并对其进行了优化，但我想为此定义一个可衡量的要求。
为了使人们不会注意到滞后，响应应该多快发生？例如，按下键盘按键与屏幕上出现字母之间的最小可检测延迟是多少？在什么情况下，进一步的优化不会对人类产生任何影响？
许多显示器的刷新率大约在 60-120Hz 范围内。这是否意味着神奇数字约为 8-16 毫秒？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
作为一般规则，我发现任何快于 100 毫秒的事物都倾向于被视为“即时”。如果比这长得多，延迟肯定会变得明显。当然，这会因人而异，并且还取决于发生延迟的上下文。
您可能会发现此示例很有帮助：http://jsfiddle.net/QGmBy/
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/
考虑到“按键”事件和屏幕上显示的字母作为两个单独的框架，意味着如果用户在看屏幕时按下某个键，他将希望随后准确地看到它。 “恰好之后”意味着它应该具有 60 Hz 或更高的响应时间。
因此，确实应该以 8-16 毫秒为目标，因为它会产生与电影中看到的效果相同的效果。换句话说，用户对于这些值不会有延迟的感觉。
但是，您必须记住，键盘有自己的轮询时间，并且与脚本本身不一定相关的额外延迟可能会干扰其时间。出于这些原因，以高于 60 Hz 的值为目标将为您提供更大的安全裕度，以应对可能增加轻微延迟的其他可能影响。
另外值得注意的是，在某些应用程序中，100 毫秒的延迟可能看起来不明显，但实际上很明显，因为它对应于 10 Hz，如果您以该刷新率播放电影，您很可能会意识到电影每个帧之间的间隙。因此，不应在足够通用的上下文中真正考虑该值。
人眼的敏感度对于不同条件和图像部分是不同的，因此您应该小心并根据需要考虑更高的刷新率，以适应这一点。
此链接提供有关人眼如何感知屏幕特征及其变化的更多信息，以及可能会让您根据脚本的视觉效果了解在给定上下文中应该瞄准哪种刷新率。
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.
我听说有一条经验法则：100 毫秒就足够快了。
我会尝试找到一个链接...
编辑：
可感知的最短应用程序响应延迟是多少？
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?
如果事件仅发生一次，则 100 毫秒应该是上限。如果事件是连续运动的一部分，那么应该是大约 10-15 毫秒，因为如果此类延迟发生在滑动物体（一次 [一个或多个] 像素）之类的情况下，100 毫秒的延迟可能会很明显。排一个接一个。
它还在某种程度上取决于上下文，即延迟的内容。按键事件、滑入事件、其他机器上发生的实时事件，所有这些都会有不同的“容差”级别:)
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 :)