1. 300ms延遲的產生緣由
2. 點透行為
假設有兩個層級，a和b；a在上面，b在下面。 如果a監聽touch事件(zepto的tap事件)，而且b上有個鏈結(或者監聽click事件)，那麼當touch a後，先後觸發了touchstart和touchend事件，touchend後a層隱藏，而此刻會觸發在document最前面b的click事件；這就是點透行為。
3. 解決方法
設定不能縮放：user-scalable=no。 不能縮放就不會有雙擊縮放操作，因此click事件也就沒了300ms延遲，這個是chrome首先在android中提出的。
設定顯示寬度：width=device-width。chrome 開發團隊不久前宣布，在 chrome 32 這一版中，他們將在包含 width=device-width 或者置為比 viewport 值更小的頁面上禁用雙擊縮放。當然，沒有雙擊縮放就沒有 300 毫秒點選延遲。
ie的指標事件 (pointer events)：設定touch-action:none，根據規範，touch-action 屬性決定 「是否觸控操作會觸發使用者**的預設行為。這包括但不限於雙指縮放等行為」。
從實際應用的角度來看，touch-action決定了使用者在點選了目標元素之後，是否能夠進行雙指縮放或者雙擊縮放。因此，這也相當完美地解決了 300 毫秒點選延遲的問題。
鑑於上述的3種解決方案，現在較為通用的meta設定為：
上述的3種解決方案可以解決chrome android和ie10+下的300ms問題，但是對其他瀏覽器還需要特定的解決方案。
指標事件的 polyfill
指標事件的 polyfill 比較多，以下列出比較流行的幾個。google 的 polymer，微軟的 handjs和@rich-harris 的 points
fastclick
fastclick 是 ft labs 專門為解決移動端瀏覽器 300 毫秒點選延遲問題所開發的乙個輕量級的庫。簡而言之，fastclick 在檢測到 touchend事件的時候，會通過 dom 自定義事件立即觸發乙個模擬click事件，並把瀏覽器在 300 毫秒之後真正觸發的 click事件阻止掉。
5. fastclick
fastclick通過判斷瀏覽器型別決定其是不是需要執行，下面幾種場景下不會執行fastclick邏輯：
註冊了touchstart、touchend等事件，監聽touchstart決定事件物件的target、時間、位置等資訊；通過touchend得到touch的結束時間。如果touch時長大於700ms，則是長按事件；如果連續兩次touchend的時間間隔小於200ms，那麼認定為快速點選，特殊對待；排除上面兩張情況，就通過clickevent = document.createevent('mouseevents'); initmouseevent; dispatchevent手動觸發click事件。
移動端click事件300ms延遲
一般情況下，如果沒有經過特殊處理，移動端瀏覽器在派發點選事件的時候，通常會出現300ms左右的延遲。也就是說，當我們點選頁面的時候移動端瀏覽器並不是立即作出反應，而是會等上一小會兒才會出現點選的效果。在移動web興起的初期，使用者對300ms的延遲感覺不明顯。但是，隨著使用者對互動體驗的要求越來越高...
移動端click事件延時
在移動端使用click事件會產生300ms的延遲 問題的產生 移動端存在雙擊放大的問題，所以在移動端點選事件發生時，為了判斷使用者的行為 到底是要雙擊還是要點選 瀏覽器通常會等待300ms，如果300ms之內，使用者沒有再次點選，則判定為點選事件，否則判定為雙擊縮放。為什麼要解決 線代web對效能的...
移動端模擬click事件
移動端click事件會有300ms延遲 所以用touch事件來模擬click事件，來達到點選無延遲 在這裡主要使用touch事件來控制開關，來區分手指移動還是點選情況 var onoff true 手指觸控就會觸發touchstart事件,這裡不能省略，否則onoff狀態不會再次生效 div1 on...