【感謝@jianfengye110 的熱心翻譯。如果其他朋友也有不錯的原創或譯文，可以嘗試推薦給伯樂線上。】
效能一直是網站成功的關鍵。越來越多的研究已經證明，不管是小型電商，還是像沃爾瑪那樣的連鎖店，即使是頁面載入時間方面的細微改善，都可以帶來更多的業務，更多的廣告收入，更多的使用者粘性和更多的客戶滿意度。
在過去幾年，Web開發者都是基於改善硬體或者提高頻寬速度來優化使用者體驗。但是最近幾年，爆炸式的移動Web瀏覽器的使用打破了這個途徑。低頻寬，高延遲，小記憶體，低處理器效能的移動裝置環境，迫使開發者不得不想辦法通過優化前端頁面的效能來滿足使用者的效能預期。
在強調如何解決移動端效能問題上，這篇文章總結了一些前端優化的案例，並且概括了一些加速頁面的方法和策略。
為什麼效能會影響這麼多
不論你的頁面設計地多麼有趣、漂亮、互動性好，不管是在桌面還是移動裝置上，如果頁面需要花2到3秒時間去渲染展示，那麼使用者都會很快變得不耐煩的。可以預期的是，在頁面還在載入的時候，使用者很有可能從瀏覽購買的行為轉變為點選回退鍵或者是關閉瀏覽器的行為。
不到1秒鐘的延遲甚至也會顯著地影響收入。在2006年，當時還在Google工作的Marissa Mayer說，由於使用者表示希望在一個搜尋頁上看到多於10個搜尋結果，Google就實驗性地修改為30個。但是讓人吃驚的是，在這個實驗裡，流量和投資都減少了20個百分點，顯然是由於更多的搜尋結果導致多花費了半秒時間來載入頁面。^5
使用者的期望總是在不斷的提升。2009年，Forrester研究所的Akamai的一項研究發現表明，網頁響應時間可容忍的閥值是2秒，一旦網頁相應時間超過3秒，會有40%的使用者放棄瀏覽頁面。一年之後，Akamai的另一項研究表明，超過3秒放棄瀏覽頁面的使用者比例上升到了57%。^1,7
此外，移動端的使用者希望移動裝置上的頁面效能不亞於桌面PC。由Tealeaf科技（現在已經併入IBM）委託的“Harris的互動2011移動互動調查”顯示，在前一年有過移動消費經歷的成年人中，有85%希望移動裝置上的體驗能與手提電腦或者PC上的體驗相當，甚至於更好。並且有63%的人表示，一旦他在移動裝置上的交易遇到了一個問題，他們就不會再想通過其他渠道去購買這個公司的其他產品了。^10換句話說，差勁的移動頁面效能會影響到公司其他各種平臺的銷售，這其中當然也包括線下的實體店。
移動流量正在迅速增長。對許多消費者而言，他們的手機或者平板裝置已經成為他們瀏覽網路的主要入口了，但是其效能表現卻差強人意。2011年2月，Compuware公司委託Equation 研究所做的一項研究表明，幾乎一半的移動使用者（46%）表示他們手機上的網站載入速度過慢。60%的使用者希望頁面能在3秒或者更少的時間內載入完成，74%的使用者表示，當單個頁面載入時間花費5秒或者更多的時候，他們會選擇離開這個頁面。在2012年，由Strangeloop網路（現已併入Redware）發起的一項針對200家領先的電子商務網站研究表明，3G網路環境下，平均載入時間為11.8秒（圖1），而在LTE（4G）環境下，載入時間只有輕微的改善，為8.5秒。^8
移動裝置表現效能的三種影響因素
正如上文所說的，移動裝置天生有下面三種效能限制：頻寬低，記憶體小，處理器效能低。這些效能挑戰又加上一些其他的問題，例如：
網頁比以前更大。根據HTTP Archive網站的分析，現在平均的一個web頁面需要載入超過1MB的資料，其中包含有圖片，Javascript，CSS（Cascading Style Sheets）等。更大的網頁會影響桌面PC的顯示效能。對於移動端的效能 — 特別是3G環境下的效能 — 影響更嚴重。這個影響會在今後的三年更加明顯。以現在的頁面增長速度來說，到2015年，平均的頁面大小會達到2MB。
延遲相差巨大。對LTE來說，延遲大概有34ms，對3G來說，延遲大概有350毫秒甚至更多。移動端的延遲性唯一不變的就是延遲時間永遠是不定的，即使是在同一個地點，每次的延遲都是不定的。這是由於大量的資料是通過資訊塔進行傳輸的。因此諸如天氣，甚至是持有者所面向的方向都有可能成為影響因素。
下載速度相差巨大。下載速度的範圍從3G環境下的1Mbps到LTE環境下的31Mbps。把這個和美國平均的頻寬15Mbps相比是一個很有意思的事情，3G環境比平均頻寬慢了15倍，而LTE卻能達到平均頻寬的2倍那麼快。
M.SITES並不能完全解決移動端效能的問題。
許多網站建設者嘗試針對多使用者訪問，大網頁和低流量連線的訪問頁面，開發出短小，快速，精簡的m.sites；但是，這些嘗試並沒有什麼用，當使用者有選擇權的時候，高達35%的移動使用者會選擇瀏覽完整的網站。
這些選擇瀏覽完整網站的使用者顯然比瀏覽m.sites的使用者更有購買慾望。一個研究表明，移動端每$7.00的消費中，有$5.50是來自於網站的網站瀏覽，只有$1.00是來自於m.sites，剩下的$0.50則是來自於客戶端。^9
解決問題
改善網站效能的主要策略並沒有因為從PC變成手機或者平板裝置而有變化，只是會參雜一些小的策略。
不論在PC還是在移動瀏覽器上，頁面展示需要的時間裡，只有20%是用來讀取頁面的HTML的。剩下的80%是用來載入額外的像樣式表、指令碼檔案、或者圖片這樣的資源和執行客戶端的程式。
三個主要的改善效能的策略是：
- 減少每個頁面需要獲取額外資源的HTTP請求數
- 減少每個請求載入的大小
- 優化客戶端執行的優先順序和指令碼執行的效率
由於行動網路通常比桌面機器的網路慢，所以減少請求數和請求載入量是非常重要的。由於移動端的瀏覽器解析HTML和執行JavaScript的效率比桌面PC低，所以優化客戶端程式也是非常關鍵的。另外，移動端瀏覽器的快取大小比桌面PC低，所以需要有方法能重複利用本地的快取資源。
文章剩餘部分總結了能解決這些問題的方法。雖然這些方法大都可以自動化解決，當然也可以由有經驗的前端工程師來手動解決。關鍵就是要知道人工解決這些技術的方法如何控制資源的請求。通常在CMS（內容管理系統）或者其他Web應用中，有些頁面包含一些自動生成好的或者離線的HTML片段、CSS或者Javascript檔案，這樣的頁面開發者就不需要去優化它們了。
減少請求
最大的效能漏洞就是一個頁面需要發起幾十個網路請求來獲取諸如樣式表、指令碼或者圖片這樣的資源。這個在相對低頻寬和高延遲的移動裝置連線上來說影響更嚴重。CDNs（內容分發網路）把資源放在離使用者地理位置更近的地方對解決這個問題能起到很大作用，但是比起獲取請求，大量的請求對頁面載入時間的影響更為嚴重。而且最近的發現表明，CDNs對移動端使用者的效能影響越來越低。
下面的章節討論了簡化HTTP請求的幾種方法。
整合資源
對開發者來說，將Javascript程式碼和CSS樣式放到公共的檔案中供多個頁面共享是一種標準的優化方法。這個方法能很簡單的維護程式碼，並且提高客戶端快取的使用效率。
在Javascript檔案中，要確保在一個頁面中相同的指令碼不會被載入多次。當大團隊或者多個團隊合作開發的時候，這種冗餘的指令碼就很容易出現。你可能會對它的發生頻率並不低感到非常吃驚。
Sprites是css中處理圖片的一項技術。Sprites就是將多張圖片整合到一個線性的網狀的大圖片中。頁面就可以將這個大圖片一次性獲取回來並且做為css的背景圖，然後使用css的背景定位屬性展示頁面需要的圖片部分。這種技術將多個請求整合成一個，能顯著地改善效能。
實現小貼士：平穩地改進但是需要對資源有控制許可權。根據開發者的網站不同許可權，一些資源並不需要被整合起來（例如，一些由CMS生成的資源）。還有，對於一些外部域引用的資源，強行整合可能會導致問題。需要注意的是，整合資源對手機瀏覽器來說是一把雙刃劍。整合資源確實會在首次訪問減少請求，但是大的資原始檔可能會導致快取失效，所以，需要小心地使用各種技術整合資源，以達到優化本地儲存的目的。
使用瀏覽器快取和本地快取
現在所有的瀏覽器都會使用本地資源去快取住那些被Cache-Control或者Expires頭標記的資源，這些頭能標記資源需要快取的時間。另外，ETag（實體標籤）和Last-Modified頭來標識當資源過期後是否需要重新請求。瀏覽器為了減少不必要的伺服器請求，儘可能地從本地快取中獲取資源，並且將那些已經過期的、或者當快取空間減小的時候將那些很久不用的資源進行清理。瀏覽器快取通常包括圖片，CSS，Javascript程式碼，這些快取能合理地提高網站的效能。（比如為了支援後退和前進的按鈕，使用一個單獨的快取來儲存整個渲染的頁面）。
移動瀏覽器快取，通常是比桌面PC小的多，這就導致了快取的資料會很經常被清理。HTML5的快取基於瀏覽器快取提供了一個很好的替換方案。Javascript的localStorage已經在所有主流的桌面和移動端瀏覽器上都實現了。使用指令碼程式碼能簡便地支援HTML5的localStorage操作，可以讀寫鍵值資料，每個域名大概有5MB的容量。雖然不同的移動瀏覽器上讀寫速度相差很大，但是localStorage大容量的快取使得它很適合作為客戶端的快取。從localStorage獲取資源明顯快於從伺服器上獲取資源，而且在大多數移動裝置上也比依靠快取頭或者瀏覽器的本地快取更靈活可靠。這是移動瀏覽器比桌面PC更有優勢的一個地方，在桌面PC上，本地快取仍然優先使用標準的瀏覽器快取，導致桌面PC本地快取的效能落後於移動瀏覽器。
實現小貼士：需要進一步考慮。雖然localStorage的機制易於實現，但是它的一些控制機制卻是非常複雜的。你需要考慮到快取帶給你的所有問題，比如快取失效（什麼時候需要刪除快取？），快取丟失（當你希望資料在快取中的時候它並不在怎麼辦？），還有當快取滿的時候你怎麼辦？
首次使用的時候在HTML中嵌入資源
HTML的標準是使用連結來載入外部資源。這使得更容易在伺服器上（或者在CDN上）操作更新這些資源，而不是在每個頁面上修改更新這些資源。根據上文討論的，這種模式也使得瀏覽器能從本地快取而不是伺服器上獲取資源。
但是對還沒有快取到瀏覽器localStorage的資源來說，這種模式對網站的效能有負面的影響。一般來說，一個頁面需要幾十個單獨的請求來獲取資源從而渲染頁面。所以說，從效能的角度來說，如果一個資源沒有很高的被快取的機率的話，最好把它嵌入到頁面的HTML中（叫inlining），而不是使用連結外部。指令碼和樣式是支援內嵌到HTML中的，但是圖片和其他的二進位制資源其實也是可以通過內嵌包含base64編碼的文字來嵌入到HTML中的。
內嵌的缺點是頁面的大小會變得非常大，所以對於Web應用來說，關鍵的是能夠跟蹤分析這個資源什麼時候需要從服務端獲取，什麼時候已經快取到客戶端了。另外，在第一次請求資源後必須能夠使用程式碼在客戶端快取資源，因此，在移動裝置上，使用HTML5 localStorage能很好地做到內嵌。
實現小貼士：平穩處理。由於不知道使用者是否已經訪問過這個頁面了，所以需要網站有機制能生成不同版本的頁面。
使用HTML5服務端傳送事件
Web應用已經使用了各種從伺服器上輪詢資源的方法來持續地更新頁面。HTML5的EventSource物件和Server-Sent事件能通過瀏覽器端的JavaScript程式碼開啟一個服務端連線客戶端的單向通道。服務端可以使用這個寫通道來傳送資料，這樣能節省了HTTP建立多個輪詢請求的消耗。這種方式比HTML的WebSocket更高效。WebSocket的使用場景是，當有許多客戶端和服務端的互動的時候（比如訊息或者遊戲），在全雙工連線上建立一個雙向通道。
實現小貼士：需要進一步考慮。這個技術是基於具體的技術實現的。如果你的網站當前是使用其他的Ajax或者Comet技術來輪詢的，轉變成Server-Sent 事件需要重構網站的Javascript程式碼。
消除重定向
當使用者在一個移動裝置上訪問桌面PC網站的時候，Web網站應用通常讀取HTTP的user-agent頭來判斷這個使用者是否是來自移動裝置的。然後應用會傳送帶有空HTTP body和重定向HTTP地址頭的HTTP 301（或者302）請求，把使用者重定向到網站的移動版本上去。但是，這個額外的客戶端和服務端的互動通常在行動網路上會消耗幾百毫秒。因此，在原先的請求上傳遞移動的web頁會比傳遞一個重定向的資訊並讓客戶端再請求移動頁面更快。
對於那些想要在移動裝置上看桌面PC網站的使用者來說，你可以在移動web頁面上提供一個連結入口，這樣也能同時表示你的網站是並不提倡這種行為的。
實現小貼士：雖然這個技術在理論上是簡單的，但是實際上並不易於實施。由於有些m.sites是宿主在其他地方的，所以許多網站會選擇重定向到一個不同的伺服器上。有的網站則是會在重定向請求的時候種植上Cookie告訴Web應用這個使用者是在使用移動裝置。這種方法可能對web應用來說更容易控制。
減少資源負載
大小問題。渲染小頁面更快，獲取小資源也更快。減小每個請求的大小通常不如減少頁面請求個數那麼顯著地提高效能。但是，有些技術在效能方面，特別是在需要對頻寬和處理器效能精打細算的移動裝置環境下，仍然是能帶來很大利益的。
壓縮文字和影象
諸如gzip這樣的壓縮技術，依靠增加服務端壓縮和瀏覽器解壓的步驟，來減少資源的負載。但是，一般來說，這些操作都是被高度優化過了。而且測試表明，壓縮對網站還是起到優化效能的作用的。那些基於文字的響應，包括HTML，XML，JSON（Javascript Object Notation），Javascript，和CSS可以減少大約70%的大小。
瀏覽器在Accept-Encoding請求頭中申明它的解壓縮技術，並且當它們接收到服務端返回的Content-Encoding響應頭標示的時候，就會按照這個響應頭自動做解壓操作。
實現小貼士：易於實現。如果設定正確的話，現在所有的Web伺服器都支援壓縮響應。但是，也有一些桌面PC的安全工具會將請求頭中的Accept-Encoding頭去掉，這樣即使瀏覽器支援解壓縮，使用者也無法獲取到壓縮後的響應。
程式碼簡化
簡化通常是使用在指令碼和樣式檔案中，刪除一些不必要的字元，比如空格，換行符，或者註釋等。不需要暴露給外部的命名就可以被縮短為一個或者兩個字元，比如變數名。合適的簡化資源通常在客戶端不需要做任何其他的處理，並且平均減少20%的資源大小。內嵌在HTML中的指令碼和樣式檔案也是可以精簡的。有很多很好的庫來做精簡化的操作，這些庫一般也同時會提供合併多個檔案這樣減少請求數的服務。
簡化帶來的好處並不侷限於減少頻寬和延遲，對於那些移動裝置上快取無法儲存的過大資源來說，也是很有改善的。Gzip在這個方面並沒有任何幫助，因為資源是在被解壓後才被快取起來的。
實現小貼士：易於實現。Google的Closure Compiler已經難以置信地完成了理解和簡化Javascript的工作。但是CSS的簡化則沒有那麼容易，因為對不同瀏覽器來說有不同的CSS技術能迷惑CSS簡化工具，然後讓CSS簡化後無法正常工作。必須要注意的是，已經有這樣的案例了，即使只是刪除了不必要的字元，簡化工作也有可能破壞頁面。所以當你應用簡化技術之後，請做一下完整的功能測試工作。
調整圖片大小
圖片通常是佔用了Web頁面載入的大部分網路資源，也佔用了頁面快取的主要空間。小螢幕的移動裝置提供了通過調整圖片大小來加速傳輸和渲染圖片資源的機會。如果使用者只是在小的移動瀏覽器視窗中看圖片的話，高解析度的圖片就會浪費頻寬、處理時間和快取空間。
為了加速頁面渲染速度和減少頻寬及記憶體消耗，可以動態地調整圖片大小或者將圖片替換為移動裝置專用的更小的版本。不要依靠瀏覽器來將高解析度的圖片轉換成小尺寸的圖片，這樣會浪費頻寬。
另外一個方法是先儘快載入一個低解析度的圖片來渲染頁面，在onload或者使用者已經開始和頁面互動以後將這些低解析度的圖片替換成為高解析度的圖片。
實現小貼士：特別應用在高度動態化的網站是有優勢的。
使用HTML5和CSS 3.0來簡化頁面
HTML5包括了一些新的結構元素，例如header，nav，article和footer。使用這些語義化的元素比傳統的使用div和span標籤能使得頁面更簡單和更容易解析。一個簡單的頁面更小載入更快，並且簡單的DOM（Document Object Model）代表著更快的JavaScript執行效率。新的標籤能很快地應用在包括移動端的新瀏覽器版本上，並且HTML5設計讓那些不支援它的瀏覽器能平穩過渡使用新標籤。
HTML5的一些表單元素提供了許多新屬性來完成原本需要javascript來完成的功能。例如，新的placeholder屬性用於顯示在使用者輸入進入輸入框之前顯示的介紹性文字，autofocus屬性用於標示哪個輸入框應當被自動定位。
也有一些新的輸入框元素能不用依靠Javascript就可以完成一些通用的需求。這些新的輸入框型別包括像e-mail，URL，數字，範圍，日期和時間這樣需要複雜的使用者互動和輸入驗證的元素。在移動瀏覽器上，當需要輸入文字的時候，彈出的鍵盤通常是由特定的輸入框型別來做選擇的。不支援指定的輸入型別的瀏覽器就會只顯示一個文字框。
另外，只要瀏覽器支援內建的層次，圓角，陰影，動畫，過渡和其他的圖片效果，CSS 3.0就能幫助你建立輕便簡易的頁面了，而這些圖片效果原先是需要載入圖片才能完成的。這樣，這些新特性就能加速頁面渲染了。
有很多Web站點都提供哪些移動或者桌面瀏覽器支援哪項效能的更新說明。（例如：http://caniuse.com/ 和 mobilehtml5.org）。
實現小貼士：需要進一步考慮。人工地做這些改動是非常複雜和耗時的。如果你使用CMS，它可以幫你生成許多你不需要控制的HTML和CSS。
優化客戶端的程式處理
瀏覽器按照什麼順序來執行程式碼生成一個頁面，和頁面複雜性及JavaScript的技術選擇，都對效能有很大的影響。特別在客戶端相對較慢的CPUs和少記憶體的移動端中尤為明顯。下面的章節提供一些策略來提升頁面處理的效能。
延遲渲染”BELOW-THE-FOLD”內容
可以確定的是如果我們將不可見區域的內容延遲載入，那麼頁面就會更快地展現在使用者面前，這個區域叫做”below the fold”。為了減少頁面載入後需要重新訪問的內容，可以將圖片替換為正確的高寬所標記的<img>標籤。
實現小貼士：平穩處理。一些好的Javascript庫可以用來處理這些below-the-fold 延遲載入的影象。^12
延遲讀取和執行的指令碼
在一些移動裝置上，解析Javascript程式碼的速度能達到100毫秒每千位元組。許多指令碼的庫直到頁面被渲染以後都是不需要的載入的。下載和解析這些指令碼可以很安全地被推遲到onload事件之後來做。例如，一些需要使用者互動的行為，比如託和拽，都不大可能在使用者看到頁面之前被呼叫。相同的邏輯也可以應用在指令碼執行上面。儘量將指令碼的執行延遲到onload事件之後，而不是在初始化頁面中重要的可被使用者看到的內容的時候執行。
這些延遲的指令碼可能是你自己寫的，更重要的是，也有可能是第三方的。對廣告、社交媒體部件、或者分析的差勁的指令碼優化會導致阻塞頁面的渲染，會增加珍貴的載入時間。當然，你需要小心地評估諸如jquery這樣為移動網站設計的大型指令碼框架，特別當你僅僅只是使用這些框架中的一些物件的時候更要小心評估。
實現小貼士：平穩處理。許多第三方的框架現在提供延遲載入的非同步版本的API。開發者只需要將原先的邏輯轉化到這個非同步版本。一些JavaScript要做延遲載入會有些複雜，因為在onload之後執行這些指令碼需要注意很多注意事項。（例如，你有個指令碼需要繫結到onload事件上，你需要做什麼？如果你將指令碼延遲到onload事件之後，就一定就會失去很多執行的時機。）
使用Ajax來增強程式
Ajax（Asynchronous JavaScript and XML）是一項使用XHR（XMLHttpRequest）物件來從Web伺服器上獲取資料的技術，它並不需要更新正在執行的頁面。Ajax能更新頁面上的某個部分而不需要重新構建整個頁面。它通常用來提交使用者的互動相應，但是也可以用來先載入頁面的框架部分，然後當使用者準備好瀏覽網頁的時候再填充詳細的內容。
儘管是這個名字，但是XMLHttpRequest並不強制要求你只能使用XML。你可以通過呼叫overrideMineType方法來制定”application/json”型別來使用json替換XML。使用JSON.parse會比使用原生的eval()函式快了幾乎兩倍，並且更為安全。
同時，切記Ajax的返回響應也會得益於那些應用在普通的返回響應的優化技術上面。確保對你的Ajax返回響應使用了快取頭，簡化，gzip壓縮，資源合併等技術。
實現小貼士：由於這個技術是根據具體應用不同而不同的，所以很難量化。或許由於跨域問題，你需要使用XHR2，這個技術能使用外部域的資源，從而能進行跨域的XHR請求。
根據網路狀況進行適配處理
由於使用更多頻寬會使用更多行動網路的費用，所以只有能檢測網路的型別才能使用針對特定網路的優化技術。例如，預載入未來使用到的請求是非常聰明的做法，但是如果使用者的頻寬很稀有，並且載入的有些資源是永遠不會用到的話，這個技術就是不合理的了。
在Android 2.2+，navigator.connection.type屬性的返回值能讓你區分Wifi和2G/3G/4G網路。在Blackberry上，blackberry.network也能提供相似的資訊。另外，服務端通過檢測請求中的User-Agent頭或者其他的嵌入到請求中的資訊能讓你的應用檢測到網路狀況。
實現小貼士：需要進一步考慮。檢測網路資訊的API最近已經有所變化了。^11 介面現在不是直接定義Wi-Fi，3G等網路狀況，而是給出了頻寬資訊和諸如“非常慢，慢，快和非常快”這樣的建議。有個屬效能給出估計的MB/s值和一個“meterd”的Boolean值來表示它的可信度，但是對瀏覽器來說，很難根據這個來判斷環境。判斷當前網路環境然後適配仍然是一種最好的方法，但是這種方法正在被考慮被替換。
對多執行緒來說盡量使用HTML5的WEB WORKER特性
HTML5中的Web Worker是使用多個執行緒併發執行Javascript程式。另外，這種特別的多執行緒實現能減少困惑開發者多年的，在其他平臺上遇到的問題。例如，當一個執行緒需要改變一個正在被其他執行緒使用的資源該如何處理。在Web Worker中，子執行緒不能修改主使用者介面（UI）執行緒使用的資源。
對提高移動站點的效能來說，Web Worker中的程式碼很適合用來預處理使用者完成進一步操作所需要的資源的，特別是在使用者的頻寬資源不緊缺的情況下。在低處理器效能的移動裝置上，過多的預載入可能會干擾當前頁面的UI響應。使用多執行緒程式碼，讓Web Worker物件（並且儘可能使用localStorage來快取資料）在另外一個執行緒中操作預載入資源，這樣就能不影響當前的UI表現了。
要特別說明的是，Web Worker只在Android 2.0以上的版本實現，而且iphone上的ios5之前的版本也不支援。在桌面PC上，總是落後的IE只在IE 10才支援Web Worker。
實現小貼士：平穩過渡。雖然這項技術並不是非常難實現，但是對Web Workers來說，有一些限制需要強制遵守。Web Workers不能進入到頁面的DOM，也不能改變頁面上的任何東西。Web Worker很適合那種需要後臺計算和處理的工作。
將CLICK事件替換成TOUCH事件
在觸控式螢幕裝置上，當一個使用者觸碰螢幕的時候，onclick事件並沒有立即觸發。裝置會使用大約半秒（大多數裝置差不多都是300毫秒）來讓使用者確定是手勢操作還是點選操作。這個延遲會很明顯地影響使用者期望的響應效能。要使用touchend事件來替換才能解決。當使用者觸碰螢幕的時候，這個事件會立即觸發。
為了要確保不會產生使用者不期望的行為，你應該也要使用touchstart和touchmove事件。例如，除非同時有個touchstart事件在button上，否則不要判斷touchend事件在button上就意味著點選行為 — 因為使用者有可能從其他地方觸碰開始，然後拖拽到button上觸碰結束的。你也可以在touchstart事件之後使用touchmove事件來避免將touchend事件誤判為點選，當然前提是需要假設拖拽的手勢並不是預期產生點選行為。
另外，你也需要去處理onclick事件來讓瀏覽器改變button的外觀從而標識為已點選的狀態，同時你也需要處理那些不支援touch事件的瀏覽器。為了避免程式碼在touchend和onclick程式碼中重複執行，你需要在確保使用者觸碰事件已經在touchend執行了之後，在click事件中呼叫preventDefault和stopPropagation方法。^4
實現小貼士：需要進一步考慮。這種技術需要更多工作才能在一個頁面中增加和維護連結。touch事件的程式碼必須考慮其他手勢，因為替換click的還有可能是縮放或者敲擊動作。
支援SPDY協議
應用層HTTP和HTTPS協議導致的一些效能瓶頸，使得不論是桌面還是移動端的網站都非常難受。在2009年，谷歌開始研發一種叫做SPDY（諧意是”speedy”）的協議來替換已有的協議，這種協議宣稱能突破這些限制。這個協議的目標是讓多種瀏覽器和多種Web服務都能支援，所以這個協議是開源的，但是初步地，只有Google的Chrome瀏覽器（在版本10及之後的）和google的站點支援。一旦一個Web服務支援SPDY，那麼它上面的所有站點都可以和支援這個協議的瀏覽器使用SPDY進行互動。將SPDY應用在25個top100的Internet網站上，Google收集到的資料是網站的速度會改善27%到60%不等。^2
SPDY自動使用gzip壓縮所有內容，和HTTP不同的是，它連header的資料也使用gzip壓縮。SPDY使用多執行緒技術讓多個請求流或者響應流能共用一個TCP連線。另外SPDY允許請求設定優先順序，比如，頁面中心的視訊會比邊框的廣告擁有更高的優先順序。
或許SPDY中最變革性的發明就是流是雙向的，並且可以由客戶端或者服務端發起，這樣能使得資訊能推送到客戶端，而不用由客戶端發起第一次請求。例如，當一個使用者第一次瀏覽一個站點，還沒有任何站點的快取，這個時候服務端就可以在響應中推送所有的請求資源，而不用等候每個資源被再次獨立請求了。作為替換協議，服務端可以傳送暗示給客戶端，提示頁面需要哪些資源，同時也允許由客戶端來初始化請求。即使是使用後一種這樣的方式也比讓客戶端解析頁面然後自己發現有哪些資源需要被請求來得快。
雖然SPDY並沒有對移動端有什麼特別的設定，但是移動端有限的頻寬就使得如果支援SPDY的話，SPDY在減少移動網站的延遲是非常有用的。
實現小貼士：依據網站和服務的環境來進行平穩操作或進一步考慮。Google有一個SPDY模組支援Apache2.2 – mod_spdy – 這個模組是免費的；但是mod_spy有執行緒上的問題，並且和mod_php協作並不是很好，所以要求你使用這個技術的時候要確保你的網站的正常執行。^6
永遠別忘記測試！
如果缺少了持續和仔細的測試提醒，效能的優化就只是討論而已，是無法完成的。如果沒有指定基準做比較，你係統上的任何改動都僅僅是理論而已。如果沒有真實的測試資料，猜測效能的瓶頸是毫無意義的。
有很多開源和通用的工具能進行整合測試，並且能進行不同地域和頻寬/延遲的測試。另外，RUM（real user monitoring）工具能將測試環境從實驗室變成不可預測的真實使用者行為。
觀察移動裝置的測試選擇和桌面場景一樣。如果你在選擇一個自動化的解決方案，請確保使用一個能持續測試，並且能區分出應用優化方法前後的變化的解決方案。
如果效能優化如果只是在發展過程中的一個步驟而已，它不會有什麼效果的。它必須成為一個持續改善網站的一部分。
參考：
1. Bustos, L. 2009. Every second counts; how website performance impacts shopper behavior. GetElastic;http://www.getelastic.com/performance/.
2. Chromium Projects. SPDY: an experimental protocol for a faster Web;https://sites.google.com/a/chromium.org/dev/spdy/spdy-whitepaper.
3. Everts, T. 2013. Case study: how effective are CDNs for mobile visitors. Web Performance Today;http://www.Webperformancetoday.com/2013/05/09/case-study-cdn-content-delivery-network-mobile-3g/.
4. Fioravanti, R. 2011. Creating fast buttons for mobile Web applications. Google Developers;http://code.google.com/mobile/articles/fast_buttons.html.
5. Linden, G. 2006. Marissa Mayer at Web 2.0. Geeking with Greg;http://glinden.blogspot.com/2006/11/marissa-mayer-at-Web-20.html.
6. mod-spdy; http://code.google.com/p/mod-spdy/.
7. PhoCusWright. 2010. PhoCusWright/Akamai study on travel site performance;http://connect.phocuswright.com/2010/06/phocuswrightakamai-study-on-travel-site-performance/;http://www.akamai.com/dl/whitepapers/Akamai_PCW_Travel_Perf_Whitepaper.pdf.
8. Radware. 2011. Case studies from the mobile frontier: the relationship between faster mobile sites and business KPIS; http://www.strangeloopnetworks.com/resources/research/state-of-mobile-ecommerce-performance/.
9. Bixby, J. 2012. 2012 state of mobile e-commerce performance;http://www.strangeloopnetworks.com/resources/videos/case-studies-from-the-mobile-frontier-the-relationship-between-faster-mobile-sites-and-business-kpis-video/.
10. Tealeaf. 2011. Report on the Mobile Customer Experience. Based on the Harris Interactive 2011 Mobile Transactions Survey.
11. W3C. 2012. Network Information API; http://www.w3.org/TR/netinfo-api/.
12. YUI. ImageLoader. Yahoo! User Interface Library; http://yuilibrary.com/yui/docs/imageloader/.