300毫秒延迟_可避免300毫秒的点击延迟

300毫秒延迟

On touch devices, a click event has a 300ms delay before firing. The reason for this the delay is that browsers need that buffer to make sure you aren’t going to double-tap on anything. The result is that if you use click events blindly, that delay creates a noticeable lag as users interact with elements on your page.

在触摸设备上，点击事件在触发前有300ms的延迟 。 延迟的原因是浏览器需要该缓冲区以确保您不会双击任何东西。 结果是，如果您盲目地使用点击事件，则当用户与页面上的元素进行交互时，这种延迟会产生明显的延迟。

There has been a Google + post by Rick Byers floating around the last few days claiming the best way to deal with the delay was to eliminate the double-tap zoom altogether. With no double-tap gesture to worry about, browsers no longer need that 300ms buffer and can now fire click events immediately.

最近几天，Rick Byers在Google+上发布了一条帖子，声称应对延迟的最佳方法是完全消除两次缩放。 无需担心两次点击手势，浏览器不再需要300ms的缓冲，现在可以立即触发点击事件。

One of the recommendations made was to kill the double-tap gesture on Chrome and Firefox for Android. To do this, you have to kill scaling:

提出的建议之一是取消Chrome和Android版Firefox上的双击手势。 为此，您必须取消缩放：

On Chrome Android and Firefox this involves using the “viewport” meta tag to disable zooming (with user-scalable=no or initial-scale=1,maximum-scale=1)

在Chrome Android和Firefox上，这涉及使用“视口”元标记来禁用缩放(其中user-scalable = no或initial-scale = 1，maximum-scale = 1)

The popularity of the post concerned me because while the comments discussed it a bit, the original post didn’t mention one massive, glaring issue with this recommendation: the impact on accessibility.

该帖子的受欢迎程度使我感到担忧，因为尽管评论对此进行了一些讨论，但原始帖子并未提及此建议的一个明显的重大问题：对可访问性的影响。

Disabling scaling means not only is there no double-tap to zoom, but there is no pinch-to-zoom either. Many users depend on this functionality for accessibility: for them, disabling scaling effectively renders your site broken and useless.

禁用缩放意味着不仅没有双击可以缩放，而且也没有捏合缩放。 许多用户都依赖此功能来实现可访问性：对他们而言，有效地禁用缩放功能会使您的站点损坏且无用。

So my advice is to avoid this like the plague in nearly all scenarios, for several reasons:

因此，我的建议是在几乎所有情况下避免类似瘟疫的发生，原因如下：

• While only Chrome and Firefox for Android will benefit from it from a performance perspective, everyone loses out on an important accessibility feature. For users who require the ability to zoom to use a site, you’ve just broken the experience for them.

  从性能的角度来看，虽然只有Chrome和Firefox for Android会从中受益，但每个人都失去了一项重要的可访问性功能。 对于需要缩放以使用网站的用户，您刚刚为他们打破了体验。

• Chrome 32 is going to get clever and disable the double-tap to zoom feature without requiring scaling to be disabled. As long as as “the computed viewport width in CSS pixels is less than or equal to the window width” (so basically, if you’re using width=device-width in your viewport element). Double-tap zoom will be gone—as will the 300ms delay—but users will still be able to pinch-to-zoom if necessary. Cake…eating it too…all that.

  Chrome 32将变得更聪明，并在不需禁用缩放的情况下禁用双击缩放功能 。 只要“以CSS像素为单位计算出的视口宽度小于或等于窗口宽度”(基本上，如果在视口元素中使用width = device-width，则基本上如此)。 双击缩放将消失(300ms延迟也会消失)，但是如果有必要，用户仍然可以捏住缩放。 蛋糕……也吃……所有。

• iOS double-tap isn’t going anywhere anytime soon. iOS uses the double-tap gesture to provide a scroll feature so you’re still going to have to account for the delay on one of the most popular mobile browsers.

  iOS双击不会很快出现。 iOS使用双击手势来提供滚动功能，因此您仍然需要考虑最受欢迎的移动浏览器之一上的延迟。

As Patrick Lauke pointed out on Twitter, this leaves three different solutions for developers, depending on the scenario:

正如Patrick Lauke在Twitter上指出的 那样 ，根据情况，这为开发人员留下了三种不同的解决方案：

1. Use something like FastClick, to account for iOS.

   使用诸如FastClick之类的东西来说明iOS。

2. Use FastClick or kill scalability (as we’ve just discussed, a bad idea) for Chrome versions 32 and under.
   对于32及以下版本的Chrome，请使用FastClick或取消可扩展性(正如我们刚刚讨论的，这是一个坏主意)。
3. Use width=device-width in their meta tags and celebrate when Chrome 32 and later don’t have a delay.
   在他们的meta标签中使用width = device-width，庆祝Chrome 32及更高版本没有延迟。

So what’s a performance and accessibility loving developer to do if they want to get rid of the delay?

那么，如果开发人员希望摆脱延迟，那么他们热衷于性能和可访问性该怎么办？

At the end of the post, Rick states to “just switch to using FastClick”. That’s frequently my recommendation as well. FastClick does a good job of dealing with the issue—without losing the ability to pinch-to-zoom and does so at ~10kb minimized. That’s not super lightweight, but it’s not too painful either.

在帖子的结尾，Rick声明“只是切换到使用FastClick”。 通常，这也是我的建议。 FastClick在解决此问题方面做得很好-在不损失缩小缩放能力的情况下，这样做的效果最小为10kb。 那不是超级轻量级​​的，但是也不是太痛苦。

Another option is to use something like Tappy!, a normalized tap event from the always-clever folks at Filament Group. Tappy! lets you use a “tap” event that works for touch, mouse and keyboard. Not only do you avoid the 300ms delay, but the script is under 1kb when minimized (though it does require the use of jQuery or a similar framework).

另一种选择是使用Tappy之类的东西！ ，这是来自Filament Group总是聪明的人们的标准化抽头活动。 py！ 使您可以使用适用于触摸，鼠标和键盘的“轻击”事件。 您不仅避免了300ms的延迟，而且在最小化时，脚本的大小小于1kb(尽管它确实需要使用jQuery或类似的框架)。

The point being: there are ways to successfully eliminate the click delay without negatively impacting performance. Until more browsers start solving this themselves, in the present day, preserving scaling and finding another way to combat the 300ms delay is our best option.

重点是：有一些方法可以成功消除点击延迟， 而又不会对性能产生负面影响。 直到今天有更多的浏览器开始自行解决此问题时，保留缩放比例并找到另一种方法来应对300ms延迟是我们的最佳选择。

翻译自: https://timkadlec.com/2013/11/avoiding-the-300ms-click-delay-accessibly/

300毫秒延迟