300ms延遲由來
2007 年初。蘋果公司在發(fā)布首款 iPhone 前夕吹散，遇到一個問題：當(dāng)時的網(wǎng)站都是為大屏幕設(shè)備所設(shè)計的。于是蘋果的工程師們做了一些約定八酒，應(yīng)對 iPhone 這種小屏幕瀏覽桌面端站點的問題空民。這當(dāng)中最出名的，當(dāng)屬雙擊縮放(double tap to zoom)羞迷，這也是會有上述 300 毫秒延遲的主要原因。
雙擊縮放衔瓮，顧名思義，即用手指在屏幕上快速點擊兩次葫慎，iOS 自帶的 Safari 瀏覽器會將網(wǎng)頁縮放至原始比例。 那么這和 300 毫秒延遲有什么聯(lián)系呢偷办？ 假定這么一個場景。用戶在 iOS Safari 里邊點擊了一個鏈接椒涯。由于用戶可以進行雙擊縮放或者雙擊滾動的操作，當(dāng)用戶一次點擊屏幕之后祖搓，瀏覽器并不能立刻判斷用戶是確實要打開這個鏈接湖苞，還是想要進行雙擊操作。因此财骨，iOS Safari 就等待 300 毫秒，以判斷用戶是否再次點擊了屏幕滑肉。 后來摘仅，其他移動瀏覽器都復(fù)制了 iPhone Safari 瀏覽器的多數(shù)約定，包括雙擊縮放娃属。
研究表明當(dāng)延遲超過 100 毫秒，用戶就能感受到界面的卡頓掏击。 然而秩铆，出于對手指觸摸滑動的區(qū)分，移動端頁面對于觸摸事件會有 300 毫秒的延遲殴玛，導(dǎo)致多數(shù)用戶感覺移動設(shè)備上基于 HTML 的 web 應(yīng)用界面響應(yīng)速度慢。瀏覽器開發(fā)商已經(jīng)意識到這個問題寻仗，并已相繼提出了一些解決方案。
1署尤、禁止縮放
上文提到耙替，之所以有300ms延遲，主要是為了判斷用戶是否會在第一次點擊之后進行第二次點擊曹体，如果第二次點擊與第一次點擊間隔小于300ms俗扇，則認為是縮放操作混坞，因此钢坦，如果禁止頁面縮放，也就不需要等待300ms去判斷用戶的點擊香味是否為縮放操作厨诸，在移動開發(fā)中禾酱，可通過meta標簽禁止縮放
<meta name="viewport" content="user-scalable=no">
<meta name="viewport" content="initial-scale=1,maximum-scale=1">
這種方法通過完全禁用縮放避免了300ms延遲，卻大大降低了移動端頁面的可用性和可訪問性颗管，比如滓走，當(dāng)你想要放大一張圖片或者一段字體較小的文本，卻發(fā)現(xiàn)無法完成操作搅方。
2、 width=device-width Meta 標簽
除了雙擊縮放的約定外衩藤，iPhone 誕生時就有的另一個約定是涛漂，在渲染桌面端站點的時候，使用 980 像素的視口寬度而非設(shè)備本身的寬度瓢剿。所以锚沸，一張寬度為320x320像素的圖片在設(shè)備寬度為320的iPhone4上并不占滿屏幕寬度跋选，在移動段開發(fā)中哗蜈，我們可以通過 <meta> 標簽來進行配置:
<meta name="viewport" content="width=device-width">
雙擊縮放的誕生解決了在移動設(shè)備上瀏覽桌面端站點的問題前标。既然站點內(nèi)包含了 width=device-width 這一 <meta> 標簽，也就意味著這個網(wǎng)站采用了響應(yīng)式設(shè)計只搁，因此也就消除了在該站點上可能潛在的雙擊縮放需求俭尖。
這一解決方案的另一個關(guān)鍵之處在于它只是去除了雙擊縮放，但用戶仍可以使用雙指縮放 (pinch to zoom)焰望∫押ィ可見，縮放功能并非被完全禁用虑椎，也就不存在可用性和可訪問性的問題了。
3传趾、指針事件 (Pointer Events)
指針事件最初由微軟提出泥技，現(xiàn)已進入 指針事件是一個新的 web 事件系列，相應(yīng)的規(guī)范旨在使用一個單獨的事件模型镊讼，對所有輸入類型平夜，包括鼠標 (mouse)、觸摸 (touch)忽妒、觸控 (stylus) 等，進行統(tǒng)一的處理吃溅。例如鸯檬，你可以只去監(jiān)聽一個元素的 pointerdown事件，無需分別監(jiān)聽其 touchstart和 mousedown事件喧务。
有一個和點擊延遲直接相關(guān)的實現(xiàn) —— 一個名為 touch-action的新 CSS 屬性。根據(jù)規(guī)范庐冯，touch-action屬性決定 “是否觸摸操作會觸發(fā)用戶代理的默認行為。這包括但不限于雙指縮放等行為”返劲。從實際應(yīng)用的角度來看栖茉，touch-action 決定了用戶在點擊了目標元素之后，是否能夠進行雙指縮放或者雙擊縮放搔耕。因此痰娱，這也相當(dāng)完美地解決了 300 毫秒點擊延遲的問題菩收。
touch-action的默認值為 auto，將其置為 none即可移除目標元素的 300 毫秒延遲娜饵。例如，下面的代碼在 IE10 和 IE11 上移除了所有鏈接和按鈕元素的點擊延遲遍坟。
a[href], button {
-ms-touch-action: none; /* IE10 */
touch-action: none; /* IE11 */
}
但就目前而言晴股，只有 Internet Explorer 實現(xiàn)了指針事件，不過近期 Chrome 也宣布了將在未來的版本中提供支持隔节。
當(dāng)前解決方案
盡管瀏覽器開發(fā)商針對 300 毫秒延遲問題提出了一些解決方案寂呛，但目前并沒有簡單通用的方案。不過贷痪，已經(jīng)有好多開發(fā)者考慮過這一問題劫拢，并帶來了一些基于 JavaScript 的跨平臺解決方案胖缤。這些方案可以歸為兩類 —— 針對指針事件的 polyfill 和“快速點擊 (fast click)”阀圾。
1、polyfill
指針事件的 polyfill 比較多初烘，以下列出比較流行的幾個肾筐。
Google 的 Polymer
微軟的 HandJS
@Rich-Harris 的 Points
為避免 300 毫秒點擊延遲，我們主要關(guān)心這些 polyfill 是如何在非 IE 瀏覽器中模擬 CSS touch-action 屬性的吗铐，這其實是一個不小的挑戰(zhàn)。由于瀏覽器會忽略不被支持的 CSS 屬性典阵，唯一能夠檢測開發(fā)者是否聲明了 touch-action: none 的方法是使用 JavaScript 去請求并解析所有的樣式表镊逝。HandJS 也正是這么做的，但不管是從性能上來看還是其他一些復(fù)雜的方面歹啼，這都會遇到問題座菠。
Polymer 則是通過判斷標簽上的 touch-action 屬性 (attribute)，而非 CSS 代碼拓萌。下面的代碼展示了 Polymer 是如何在鏈接上模擬 CSS touch-action: none 屬性的巡莹。
<a touch-action="none">Google</a>
2、fastclick
FastClick 是 FT Labs 專門為解決移動端瀏覽器 300 毫秒點擊延遲問題所開發(fā)的一個輕量級的庫降宅。簡而言之腰根，F(xiàn)astClick 在檢測到 touchend事件的時候，會通過 DOM 自定義事件立即觸發(fā)一個模擬 click事件，并把瀏覽器在300 毫秒之后真正觸發(fā)的 click事件阻止掉劣挫。
FastClick 的使用方法非常簡單东帅，在 window load 事件之后，在 <body>用FastClick.attach()即可帐我。
window.addEventListener( "load", function() {
FastClick.attach( document.body );
}, false );
