移动端300ms延迟的由来及解决方案

一、移动端300ms点击延迟的前因后果

一般情况下，如果没有经过特殊处理，移动端浏览器在派发点击事件的时候，通常会出现300ms左右的延迟。也就是说，当我们点击页面的时候移动端浏览器并不是立即作出反应，而是会等上300ms才会出现点击的效果。在移动WEB兴起的初期，用户对300ms的延迟感觉不明显。但是，随着用户对交互体验的要求越来越高，目前移动端300ms的点击延迟逐渐变得明显而无法忍受，那么，移动端300ms的点击延迟是怎么来的呢？

问题由来：

这要追溯至 2007 年初。苹果公司在发布首款 iPhone 前夕，遇到一个问题：当时的网站都是为大屏幕设备所设计的。于是苹果的工程师们做了一些约定，应对 iPhone 这种小屏幕浏览桌面端站点的问题。这当中最出名的，当属双击缩放(doubletap to zoom)，这也是会有上述 300ms延迟的主要原因。

双击缩放，顾名思义，即用手指在屏幕上快速点击两次，iOS 自带的Safari 浏览器会将网页缩放至原始比例。那么这和300ms延迟有什么联系呢？ 假定这么一个场景。用户在 iOS Safari 里边点击了一个链接。由于用户可以进行双击缩放或者双击滚动的操作，当用户一次点击屏幕之后，浏览器并不能立刻判断用户是确实要打开这个链接，还是想要进行双击操作。因此，iOS Safari 就等待 300 ms，以判断用户是否再次点击了屏幕。鉴于iPhone的成功，其他移动浏览器都复制了 iPhone Safari 浏览器的多数约定，包括双击缩放，几乎现在所有的移动端浏览器都有这个功能。之前人们刚刚接触移动端的页面，在欣喜的时候往往不会care这个300ms的延时问题，可是如今touch端界面如雨后春笋，用户对体验的要求也更高，这300ms带来的卡顿慢慢变得让人难以接受。

也就是说，移动端浏览器会有一些默认的行为，比如双击缩放、双击滚动。这些行为，尤其是双击缩放，主要是为桌面网站在移动端的浏览体验设计的。而在用户对页面进行操作的时候，移动端浏览器会优先判断用户是否要触发默认的行为。

那有什么办法可以解决这个问题呢？

二、浏览器开发商的解决方案

浏览器开发商要对移动端浏览器本身的设计进行改善，以提供长远的解决方案。

目前，浏览器开发商的解决方案主要有一下三种方案：
1、禁用缩放
当HTML文档头部包含如下meta标签时：

<meta name="viewport" content="user-scalable=no">
<meta name="viewport" content="initial-scale=1,maximum-scale=1">

表明这个页面是不可缩放的，那双击缩放的功能就没有意义了，此时浏览器可以禁用默认的双击缩放行为并且去掉300ms的点击延迟。
这个方案有一个缺点，就是必须通过完全禁用缩放来达到去掉点击延迟的目的，然而完全禁用缩放并不是我们的初衷，我们只是想禁掉默认的双击缩放行为，这样就不用等待300ms来判断当前操作是否是双击。但是通常情况下，我们还是希望页面能通过双指缩放来进行缩放操作，比如放大一张图片，放大一段很小的文字。

2、更改默认的视口宽度
一开始，为了让桌面站点能在移动端浏览器正常显示，移动端浏览器默认的视口宽度并不等于设备浏览器视窗宽度，而是要比设备浏览器视窗宽度大，通常是980px。我们可以通过以下标签来设置视口宽度为设备宽度。

<meta name="viewport" content="width=device-width">

因为双击缩放主要是用来改善桌面站点在移动端浏览体验的，而随着响应式设计的普及，很多站点都已经对移动端坐过适配和优化了，这个时候就不需要双击缩放了，如果能够识别出一个网站是响应式的网站，那么移动端浏览器就可以自动禁掉默认的双击缩放行为并且去掉300ms的点击延迟。如果设置了上述meta标签，那浏览器就可以认为该网站已经对移动端做过了适配和优化，就无需双击缩放操作了。
这个方案相比方案一的好处在于，它没有完全禁用缩放，而只是禁用了浏览器默认的双击缩放行为，但用户仍然可以通过双指缩放操作来缩放页面。

3、CSStouch-action

以我的理解来看，指针事件的提出并不是为了解决300ms点击延迟的，而是为了使用一个单独的事件模型，对鼠标、触摸、触控等多种输入类型进行统一的处理。也就是说，移动浏览器不用再为不同的输入设备设计不同的事件，网页的开发者也不用再为不同输入类型的设备写不同的事件响应代码，而是通过统一的指针事件就可以开发出跨不同输入类型终端的应用。

跟300ms点击延迟相关的，是touch-action这个CSS属性。这个属性指定了相应元素上能够触发的用户代理（也就是浏览器）的默认行为。如果将该属性值设置为touch-action: none，那么表示在该元素上的操作不会触发用户代理的任何默认行为，就无需进行300ms的延迟判断。

三、现有的解决方案

要解决300ms点击延迟的问题，从长远来说，自然还是得浏览器开发商提供统一的最终的解决方案。但是，到目前为止，以上三种方案并不能提供很好的兼容性，对于方案一和方案二，Chrome是率先支持的，Firefox紧随其后，然而令Safari头疼的是，它除了双击缩放还有双击滚动操作，如果采用这种两种方案，那势必连双击滚动也要一起禁用；对于方案三，IE是支持的，但是其他浏览器支持不完善。具体请看这篇文章：移动端Click300ms点击延迟的来龙去脉(转)。所以，在浏览器开发商最终统一的解决方案出来之前，我们还有一些基于Javascript的现成的解决方案可以用。

1、指针事件的polyfill
现在除了IE，其他大部分浏览器都还不支持指针事件。有一些JS库，可以让我们提前使用指针事件，比如

Google 的 Polymer

微软的 HandJS

@Rich-Harris的 Points

然而，我们现在关心的不是指针事件，而是与300ms延迟相关的CSS属性touch-action。由于除了IE之外的大部分浏览器都不支持这个新的CSS属性，所以这些指针事件的polyfill必须通过某种方式去模拟支持这个属性。一种方案是JS去请求解析所有的样式表，另一种方案是将touch-action作为html标签的属性。

2、zepto等库的 tap事件

zepto 的touch模块中自定义了tap事件，用于代替click事件，表示一个轻击操作。touch模块实现tap的原理是绑定事件touchstart,touchmove和touchend到document上，然后通过计算touch事件触发的时间差，位置差来实现了自定义的tap,swipe等。
zepto自定义的tap操作虽然可以解决300ms点击延迟问题，但存在著名的“点透”问题。解决办法可以参考https://segmentfault.com/a/1190000003848737
3、FastClick
FastClick 是 FT Labs 专门为解决移动端浏览器 300 ms点击延迟问题所开发的一个轻量级的库。FastClick的实现原理是在检测到touchend事件的时候，会通过DOM自定义事件立即出发模拟一个click事件，并把浏览器在300ms之后的click事件阻止掉。

其中jquery的使用方式：https://github.com/ftlabs/fastclick

$(function() {
	FastClick.attach(document.body);
});

总结：

禁用缩放：简单，但同时也使的网页无法缩放，不适用于未对移动端浏览做适配优化的网页。
更改默认视口宽度：简单，但需要浏览器支持。
指针事件和css touch-action:新属性，可能存在浏览器兼容问题，如仅为解决点击延迟问题儿引入一整套指针事件有点过了。
tap事件：能较好解决点击延迟，并且对其他移动端触摸事件也有较好支持，但存在点透问题。
fastclick:当前较好的专门解决点击延迟的库，脚本尺寸相对较大。推荐使用

参考文献：

https://segmentfault.com/a/1190000003848737

https://www.jianshu.com/p/16d3e4f9b2a9

https://www.jianshu.com/p/6e2b68a93c88