移動性能的優化規則

文章轉自http://queue.acm.org/detail.cfm?id=2510122    用谷歌翻譯的，可能會拗口，可是頗有用！！

技術，以加快頁面加載的概述

塔米動態，RADWARE

性能一直是網站成功的關鍵。愈來愈多的研究已經證實，即便是很小的改善頁面加載時間，致使更多的銷售，更多的廣告收入，更多的粘性，範圍從小型電子商務商店如沃爾瑪等megachains的企業和更多的客戶滿意度。

多年來，Web開發人員能夠依靠穩定在硬件和帶寬的改善，以幫助實現最佳的用戶體驗。然而，近年來，移動Web瀏覽爆炸逆轉。低帶寬，高等待時間，更小的存儲器和更低的處理能力的移動設備的實施更加迫切的需求，爲了知足用戶的指望，在其前端，以優化性能。

本文總結了前端優化的狀況，並提供了一個概述的戰略和戰術，加快您的網頁，並着重於解決移動性能問題。

爲何性能事項

不管多麼有趣的，美麗的，或巧妙的互動網頁，若是他們須要超過兩個或三個秒呈現，不管是在臺式機或移動設備，用戶很快就會不耐煩。他們是可測量的可能性較小，從瀏覽到購買的轉換，甚至可能打到「後退」按鈕或關閉瀏覽器，頁面以前曾經負載。

即便不到一秒鐘的延遲顯着影響的收入。在2006年，谷歌的時候，梅麗莎·梅耶（Marissa Mayer）講述後，用戶表示，他們但願看到超過10每頁搜索結果，谷歌嘗試，而不是顯示30。谷歌的驚喜，流量和收入降低了20％，在這個實驗中，這顯然是由於更多的網頁了只是一個額外的半秒加載。

自此只升級用戶的指望。由Forrester研究公司Akamai的表明2009年的一項研究發現可接受的Web頁面響應時間的門檻，兩秒鐘發現，40％的消費者放棄一個頁面，須要更長的時間超過三秒鐘加載。僅僅一年後，作了Akamai的另外一項研究發現，三秒鐘後放棄一個頁面的用戶數已經上升到57％。^1,7

此外，移動設備上的用戶指望的性能至少是同樣好，若是不是更好的比他們的經驗他們的桌面上。哈里斯互動2011移動交易的調查，委託茶葉的技術（如今是IBM的一部分），報告，85％的成年人誰在過去一年進行移動交易預計移動體驗等於或優於網上購物使用筆記本電腦或臺式電腦，63％的受訪者表示，他們將不太可能經過其餘渠道購買來自同一家公司，若是他們經歷了一個問題，他們的手機上進行交易。¹⁰換句話說，移動性能較差傷害公司全部其餘平臺上，包括磚和砂漿。

移動流量正在迅速擴大。對於不少消費者來講，他們的手機或平板電腦已成爲他們主要的互聯網門戶網站，但性能遜於預期。方程研究表明Compuware公司於2011年2月發表的一項研究發現，幾乎一半（46％）的手機用戶說網站加載較預期緩慢本身的手機上。近60％的受訪者預計在3秒或更少的頁面加載，74％報告說，他們會留下一個單頁網站，若是花了五秒鐘或更長時間來加載。200領先的電子商務網站仍是Strangeloop網絡（如今Radware的一部分）2012年的一項研究發現，平均負載時間爲11.8秒在3G（圖1），在LTE的性能表現稍微好一點，在8.5秒。

三個手機性能的限制因素

正如已經提到的，移動設備具備固有的性能的限制：較低的帶寬，更小的存儲器和處理能力較低。這些挑戰更加複雜的外部性問題，特別是：

Web頁面是比以往更大。根據HTTP過刊，平均網頁攜帶超過1百萬字節的有效載荷，包含至少80個資源（如圖片，JavaScript，CSS（層疊樣式表）文件，等等），這有一個臺式機性能的顯着影響。其移動性能的影響，特別是3G的性能要明顯得多。這種影響將在將來三年更敏銳地感受到。在目前的增加速度，平均頁面大小可能超過2015年2 MB的。

延遲能夠有很大的不一樣，它能夠3G LTE從34毫秒到350毫秒或以上不等。移動延時是一致的，甚至在相同的位置測量時，僅在其不一致。這是因爲一些穿過塔的數據量超出了變量。因素，如天氣，甚至用戶正面臨着方向，能夠有一個顯着的影響。

下載速度也相差很大。速度範圍能夠從一個單純的1 Mbps的3G高達31 Mbps的LTE。這是有趣的比較，美國的平均寬帶速度爲15 Mbps，並指出，3G能夠高達15倍的速度比寬帶，而LTE最多能夠快兩倍。

的M.SITES不能治癒全部對於移動性能的煩惱

許多網站全部者試圖迴應高的用戶需求，大的網頁，和鏈接速度差經過開發更小，速度更快，簡裝m.sites的組合，然而，這些嘗試並不徹底有效，由於高達35％移動用戶將選擇要查看完整的網站若是提供該選項。

這些網站的訪問者顯著更可能花費比m.site遊客。一項研究發現，每移動產生的收入7.00元，經過網站生成5.50美圓。只有1.00美圓，來到經過m.sites，並經過應用程序0.50美圓。

解決問題

用法已經從桌面到手機和平板電腦，雖然已經出現了一些新的戰術，改善網站性能的主要策略並無改變。

所須要的時間，不管是在桌面或移動瀏覽器以顯示一個典型的Web頁面，只有20％的被消耗，經過加載頁面的HTML。剩餘的80％是用於加載所需的額外資源來渲染頁面，包括樣式表，腳本文件，圖像和執行客戶端處理。

提升性能的三大戰略是：

• 須要爲每一個頁面獲取資源的HTTP請求的數量減小。
• 減小所需的有效載荷的大小來完成每個請求。
• 優化客戶端的處理優先級和腳本執行效率。

因爲移動網絡一般慢於那些提供給臺式機，減小請求和有效載荷須要巨大的重要性。移動瀏覽器解析HTML和執行JavaScript的速度較慢，因此優化客戶端的處理是相當重要的。此外，手機瀏覽器緩存遠遠小於那些桌面瀏覽器，須要新的方法來利用本地存儲的可重複使用的資源。

這篇文章的其他部分總結戰術，你能夠用它來應對這些挑戰。雖然自動化工具，可用於大多數的這些作法，不少也能夠實現手動（由經驗豐富的前端開發）。關鍵是要注意，許多這些技術的人工推行的首要挑戰是對資源的控制。常常在CMS（內容管理系統）或其餘Web應用程序，網頁能夠包含HTML片斷，CSS和JavaScript文件產生或託管場外，這意味着開發人員沒必要訪問優化。

減小請求

最大的排水性能，一般須要完成幾十個網絡往返檢索資源，如樣式表，腳本和圖像。這是特別真實與相對低帶寬和高延遲的移動鏈接。地理上更接近用戶帶來內容的CDN（內容分發網絡）能夠有點幫助，但請求的數量有更大的影響頁面加載時間的距離比那些請求旅遊。此外，最近的研究結果代表，CDN的效果有限³爲移動用戶。

下面的章節中討論了幾種方法來減小HTTP請求。

整合資源

如今是標準的作法爲開發者爲普通的多個頁面之間共享文件，能夠鞏固JavaScript代碼和CSS樣式。這項技術簡化了代碼維護和客戶端緩存提升了工做效率。

在JavaScript文件，確保相同的腳本是否是下載一個頁面屢次。冗餘的腳本下載時尤爲如此大型團隊或多個團隊協做的頁面開發。如何常常發生這種狀況，它可能會讓你大吃一驚。

Spriting是一個CSS技術鞏固圖像。精靈只是結合成直線性於一體的大型圖像網格的多個圖像。頁面抓取大型圖像，一次做爲一個單一的CSS背景圖像，而後使用CSS背景定位來顯示個別組件須要在頁面上的圖像。這減小了多個請求，只有一個，顯着提升了性能。

易於實施：中等，但須要有對資源的訪問。根據控制的水平上，開發商已經在網站上，有些資源可能不可以被合併（例如，若是它們是由一個CMS）。此外，一些資源可能位於外部域，這可能會致使整合的問題。一樣重要的是要注意資源整合爲移動瀏覽器能夠是一個雙刃劍。減小的要求提升性能，是第一次，但可能沒法有效地緩存，因此要當心將鞏固技術與其餘技術相結合優化的localStorage較大的綜合資源。

使用瀏覽器的緩存和本地存儲

全部現代的瀏覽器使用本地內存來緩存已經標記的Cache-Control或Expires頭代表多久能夠緩存資源。此外，ETag的（實體標籤）和資源應如何在緩存中從新填充後，他們已過時的Last-Modified頭。瀏覽器獲取本地緩存項目儘量避免沒必要要的服務器請求，並刷新項目已過時或最近沒有使用的緩存空間運行時短。存儲在瀏覽器的對象緩存的資源一般包括圖像，CSS和JavaScript代碼，和可接受的網站性能，緩存是必不可少的。（一個單獨的緩存保存整個渲染頁面，以支持使用「後退」和「前進」按鈕。）

然而，手機瀏覽器緩存，一般比臺式機小得多，致使項目很快被刷新。HTML5 Web存儲規範提供了一個很好的替代，僅僅依靠瀏覽器緩存。已經實如今全部主流桌面和移動瀏覽器的HTML5 的localStorage JavaScript對象。支持HTML5的localStorage的腳本代碼能夠很容易地檢查，而後使用它，若是有的話，保存和讀取的鍵/值數據，每一個域通常爲5 MB。這種能力使得localStorage的客戶端緩存很是適合，雖然作不一樣的讀/寫速度爲不一樣的移動瀏覽器。它一般是顯着更快的從localStorage的檢索資源，而不是要求它從一個服務器，它是更靈活，更可靠的比僅僅依靠緩存頭和有限的大多數移動設備上的瀏覽器的緩存存儲。此外，這是移動瀏覽器是目前領先的桌面效率localStorage的性能已經落後，使用標準的瀏覽器緩存可能仍然是最好的選擇，在桌面實現的一個領域。

易於實施：先進。雖然localStorage的機制多是簡單易用，圍繞它創建一個高速緩存，並建立一些複雜性。您將須要考慮到全部的緩存，爲你處理的問題，如緩存屆滿（當你刪除項目），高速緩存未命中（若是你預計什麼東西在localStorage的，是否是？）和作什麼，當緩存滿了。

首次使用，在HTML中嵌入資源

在HTML中的標準模式，包括外部資源的連接。這使得更容易維護這些資源文件在服務器上（或在一個CDN），並更新它們上面的源，而不是在每一個許多頁面。這種模式也支持瀏覽器緩存容許緩存的資源自動獲取從高速緩存中，而不是從服務器上，如前面所討論。

然而，這種格局是否是已經緩存在瀏覽器中或在localStorage的資源，連接到外部資源的性能產生負面影響。一個典型的頁面可能須要幾十個單獨的請求，以收集所需的資源來渲染頁面。因此，從性能的角度來看，若是資源不具備高的可能性已經被緩存，它每每是最好的，資源嵌入在頁面的HTML（內聯），而不是將其存儲和外部連接到它。支持HTML腳本和樣式標記內聯這些資源，但也可使用數據URI包含base64編碼的文本版本的資源內聯圖像和其餘二進制資源。

內聯的缺點是，頁大小能夠變得很是大，因此它是關鍵的Web應用程序，使用該策略，能夠進行跟蹤時，須要該資源時，以及當它已經緩存在客戶端。此外，應用程序必須生成代碼送內嵌在第一時間後，存儲在客戶端上的資源。出於這個緣由，在移動設備上使用HTML5 的localStorage內聯是一個偉大的同伴。

易於實施：適當。這種技術須要有一個機制，產生不一樣版本的頁面基於用戶是否以前訪問該網頁的網站。

使用HTML5服務器發送事件

Web應用程序已經用於各類輪詢技術的不斷更新頁面從服務器請求新的數據。HTML5 的EventSource對象，並服務器發送事件使JavaScript代碼在瀏覽器中打開一個更加高效的單向通道，從服務器到瀏覽器。而後，服務器可使用此通道發送數據，由於它成爲可用，消除建立多個投票請求的HTTP開銷。這也是效率比HTML5 WebSockets的，這是建立一個雙向的通道過大量的客戶端-服務器交互時，被稱爲一個全雙工的鏈接，如短信或玩遊戲更豐富的協議。

易於實施：先進。這種技術是很是特定於實現的。若是您的網站目前正在使用其餘的AJAX或彗星的技術的輪詢，將使用服務器發送的事件可能須要至關多的從新編寫網站的Javascript。

消除重定向

當用戶試圖從移動設備，瀏覽到一個標準的桌面站點，Web應用程序每每會讀取用戶代理HTTP頭檢測到請求是從移動設備。而後，應用程序能夠發送一個HTTP 301（或302）響應一個空的身體和一個Location頭，將用戶重定向到網站的移動版本。然而，額外的往返到客戶端並返回到移動網站每每經過移動網絡消耗幾百毫秒。相反，它是更快地提供移動網頁直接回復到原來的請求，而不是提供一個重定向消息，而後請手機頁。

做爲一個禮貌誰喜歡查看桌面網站，甚至在他們的移動設備上的用戶，能夠提供移動網站上的連接，標誌着您的應用程序來抑制這種行爲。

易於實施：雖然這項技術在理論上很容易，它可能沒法老是可以付諸實踐。許多網站重定向到不一樣的服務器爲他們的m.sites，由於那些可能被託管在別處。其餘網站發送cookie重定向告訴Web應用程序，它們是移動的，一旦他們重定向。這多是更嚴格的控制，取決於Web應用程序。

減小有效載荷

大小事宜。較小的頁面渲染速度更快和更小的資源中提取更快。下降每一個服務器的響應的大小一般不會幫助性能儘量的數量減小爲每一個頁面須要的響應。然而，一些技術，不產生淨盈利性能，尤爲是在移動設備上，必須明智地管理帶寬和處理能力。

壓縮文本和圖像

如gzip壓縮技術下降成本略有增長處理步驟，在服務器上壓縮和解壓在瀏覽器中的有效載荷。這些操做是高度優化的，然而，測試代表，總的效果是淨的性能改善。基於文本的反應，包括HTML，XML，JSON（JavaScript對象符號），JAVASCRIPT和CSS，能夠在縮小尺寸高達70％。

瀏覽器接受編碼請求頭中宣佈本身的減壓能力，他們自動進行解壓縮，當服務器信號響應將被壓縮，在內容編碼的響應頭。

易於實施：易。全部現代的Web服務器將支持壓縮的反應，若是正確設置。不過，也有仍然桌面安全工具，將刪除請求，這將阻止用戶壓縮反應，即便他們的瀏覽器都支持它接受編碼頭。

縮小代碼

微小，一般只應用於腳本和樣式表，消除可有可無的字符，例如空格，換行符和意見。不公開的名稱，如變量名，能夠縮短到只有一個或兩個字符。正確往上的資源是用來在客戶端上沒有任何特殊的處理，文件大小平均減小約20％。在HTML網頁中的腳本和樣式塊也能夠壓縮。有不少很好的庫可用來執行微小，每每伴隨着多個文件合併成一個，這還能下降請求的服務。

微小不只下降了帶寬消耗和延遲，但也可能意味着可緩存的對象，一個是特定移動設備上的高速緩存太大的區別。Gzip壓縮是在這方面沒有任何幫助，由於對象是由瀏覽器緩存後，他們已解壓縮。

易於實施：易。從谷歌的Closure編譯器作一個使人難以置信的工做的理解和擋土牆的JavaScript。CSS壓縮是一個比較麻煩一點，由於有這麼多不一樣的瀏覽器，能夠很容易混淆minifiers或再也不正常工做後微小的CSS黑客。另外請注意，已經公佈的微小破頁的報告，即便刪除的字符不該該是必不可少的。因此，要確保任何網頁上應用此技術進行功能測試。

調整圖像

圖像每每消耗所需的網絡資源來加載網頁緩存頁面資源所需的空間，並且其大部分的大多數。小屏幕的移動設備提供了機會，經過調整圖像的超速傳輸和渲染。高分辨率圖像浪費帶寬，處理時間和緩存空間，若是用戶將只能在一個小的移動瀏覽器窗口中查看圖像。

要加快頁面渲染和減小帶寬和內存消耗，動態調整圖像在你的應用程序或更換圖像的較小版本的移動網站。不要浪費帶寬依靠在瀏覽器上的高清晰度的圖像縮放到一個較小的寬度和高度。

另外一種選擇是最初的圖像獲取頁面儘快而後將其更換爲更高分辨率的版本上的onload事件或準備開始後，用戶與頁面交互加載一個低分辨率版本。

易於實施：高級，尤爲是對於高度動態的網站。

HTML5和CSS 3.0簡化頁面

HTML5規範包括新的結構元素，如頭，導航，文章和頁腳。使用這些語義元素產生一個更簡單，更有效地解析比使用通用嵌套的div和跨度標籤頁。一個簡單的頁面體積更小，加載速度更快和更簡單的DOM（文檔對象模型）意味着更快的JavaScript執行。在新的瀏覽器版本，包括移動瀏覽器，很快被採納新的標籤和HTML5的瀏覽器還不支持它被設計爲優雅降級。

HTML5表單中的input元素支持不少新的屬性，使聲明的HTML代碼來實現，之前須要的JavaScript功能。例如，能夠指定新的佔位符屬性說明文字出現，直到用戶建立一個條目，新的自動對焦特性能夠指定哪些輸入應自動得到最初的重點。

也有一些新的輸入元素的類型，它能夠自動執行一般須要的功能不支持JavaScript。新的類型包括電子郵件，網址，數量，範圍，日期和時間，這是有效地呈現爲複雜的控制與友好的用戶界面和驗證。在移動瀏覽器，在彈出的鍵盤每每自動提供適當的按鍵選擇到指定的輸入類型時，須要輸入文字。瀏覽器不支持指定的輸入類型只會顯示一個文本框。

此外，新的CSS 3.0功能，能夠幫助建立輕量級的網頁提供內置的支持漸變，圓角邊框，陰影，動畫，過渡，之前須要被加載的圖像和其餘圖形效果。這些新功能能夠加快網頁渲染。

一些網站提供按期更新的名單顯示支持哪些功能經過桌面和移動瀏覽器（例如，http://caniuse.com/ mobilehtml5.org

易於實施：先進。手動進行這些更改是極其複雜和耗時的，若是不是不可能的。若是你使用一個CMS，它可能會產生一個很大的HTML和CSS，你有沒有控制權。

優化客戶端的處理

須要構建一個頁面瀏覽器中執行的各個步驟的順序能夠有一個主要對性能的影響，由於這樣作的頁面的複雜性和JavaScript技術的選擇。這是特別真實移動設備上的客戶端處理受制於較慢的CPU和較少的內存。如下各節提供了一些戰術，增長頁面處理的效率。

延遲呈現如下摺疊內容

你能夠向用戶看到的頁面更快，延遲加載和呈現的任何內容，若是在最初的可見區域，有時被稱爲「低於倍如下。」 爲了消除須要迴流內容後，剩下的頁面加載，圖像取代最初與的佔位符<IMG>標籤指定了正確的高度和寬度。

易於實施：適當。一些很好的JavaScript庫，可用於¹²倍低於懶圖像加載。

延遲加載和執行腳本

解析JavaScript能夠在100毫秒每千字節的代碼在某些移動設備。許多腳本庫，直到一個頁面完成渲染後不須要。下載和解析這些腳本能夠安全地推遲，直到後的onload事件。例如，腳本支持交互式的用戶行爲，如拖放，不可能被調用以前，用戶甚至已經看到的頁面。一樣的邏輯也適用於腳本的執行。儘量推遲直到onload事件後，而不是無謂地舉起初始呈如今頁面上的重要可見內容。

推遲的腳本多是你本身的，每每更重要的是，從第三方的腳本。優化不良廣告，社交媒體的小部件，或分析支持的腳本能夠阻止網頁渲染，有時還加入了寶貴秒加載時間。此外，請仔細評估使用大型腳本框架，如jQuery移動網站，特別是若是你使用的是一對夫婦只對象的框架。

易於實施：適當。如今，許多第三方框架提供了他們的API的遞延或異步版本。開發商只是切換到這些新版本。推遲可能會更復雜一些JavaScript onload事件後運行腳本（例如，你會怎麼作，若是你有一個腳本，要附加到的onload事件？若是推遲，直到onload事件後的注意事項有不少，它已經錯過了的機會）。

使用AJAX的逐步加強

AJAX（異步JavaScript和XML）是一種技術，使用的XHR（XMLHttpRequest的）的對象，從一個Web服務器取數據，而無需刷新頁面的代碼運行。AJAX使更新的數據在一節一個頁面一個頁面來顯示，而不重建整個頁面。這一般是用來響應用戶交互，但它也可使你的應用程序來加載一個頁面快速裸機版本，而後填寫更詳細的內容，而用戶已經觀看的頁面。

儘管名稱，XMLHttpRequest的不配合你只使用XML。您能夠撥打其與JSON而不是XML overrideMimeType 「應用程序/ json」和工做方法來指定。使用JSON.parse是快速和更安全的兩倍，比使用通用的eval（）函數。

此外，請記住AJAX響應將受益於不少相同的優化技術建議標準響應。能夠確定的緩存頭，微小，gzip壓縮的，資源整合，等你的AJAX響應。

易於實施：很難量化，由於這個技術是很是特定應用。因爲跨域問題，你會須要使用XHR2，以及控制外部域進行跨域XHR請求。

適應網絡鏈接

特別是隨着移動網絡可能會收取額外使用更多的帶寬，某些技術應該被使用，只有當代碼來檢測鏈接的類型相結合。例如，預加載資源預期未來的請求一般是智能的，但它可能不是一個負責任的策略，若是用戶的帶寬計量那些資源中的一些可能永遠不會被須要。

在Android 2.2 +，的navigator.connection.type屬性返回值，讓您區分Wi-Fi無線鏈接2G/3G/4G。黑莓，blackberry.network的提供相似的信息。此外，服務器端檢測的User-Agent頭嵌入在請求的數據或其餘信息，能夠提醒您的應用程序的質量，使用中的鏈接。

易於實施：先進。網絡信息API最近發生了變化，¹¹而不是定義如Wi-Fi，3G等網絡，它如今給的帶寬的信息，如「很是慢，慢，快，很是快的建議值。 「 這裏有一個屬性，試圖告訴估計MB / s的，和一個布爾「咪表」的測量，它是正確的，但瀏覽器來肯定，這是很是困難的。測量的地方，並適應多是最好的主意，但仍然是至關具備挑戰性的。

使用HTML5的WEB工人規格的多線程

在HTML5規範的Web工做者引入了多線程的併發執行JavaScript編程世界。此外，這個特殊的實現多線程消除了一直困擾的問題，與其餘平臺具體地說，發生的問題，當一個線程也被使用，另外一個線程修改資源上的多個線程的開發工做。在Web工做代碼，生成的線程不能訪問的主要用戶界面（UI）線程的資源。

爲了提升移動站點的性能，Web工做者代碼能夠是有價值的資源預壓，用戶可能須要完成將來的行動，特別是當用戶的帶寬計量。隨着移動設備的處理器能力有限，大量的預壓能夠干擾在當前頁面中的UI響應。使用多線程的代碼，採用Web工做對象（和可能的localStorage來緩存數據），預緊力資源的操做，能夠在一個單獨的線程中執行，而不影響當前的UI性能。

請注意，的Web工人規格，同時實如今Android 2.0以來，不支持，直到iOS 5的iPhone上。在桌面上，IE瀏覽器是落後的，增長10只在IE Web工做的支持。

易於實施：適當。雖然這項技術是否是很是難以實現，網絡工做者有一些限制，使他們很難找到的地方。他們沒有訪問頁面的DOM，並不能修改任何頁面上。這種作法的工做須要一種很是特殊的後臺計算或過程，很是適合做爲背景的Web工做者。

更換點擊觸摸事件的事件

在觸摸屏設備上，在onclick事件不當即開火，當用戶點擊屏幕。相反，設備最多等待半秒（300毫秒在大多數設備上），讓用戶有機會啓動一些其餘的手勢，而不是點擊。然而，這種延遲，能夠顯着阻礙用戶指望的響應性能。爲了解決這個問題，使用touchEnd事件。這一事件當即觸發的，當用戶點擊屏幕。

爲了確保用戶不會遇到意外的行爲，你可能也想使用的的touchstart和touchmove事件。例如，不要覺得，touchend一個按鈕意味着點擊除非也有一個touchstart事件的按鈕，而不是若是用戶觸摸別處，並拖累結束前觸摸按鈕。touchstart後預防治療點擊如下touchend，假設移動手勢的目的不是爲了成爲一個點擊，你可使用一個touchmove事件。

此外，您可能仍是要處理的onclick事件，以確保瀏覽器改變了外觀的按鈕，點擊狀態顯示，並支持瀏覽器不處理觸摸事件。爲了不重複的代碼執行時，touchend和火的onclick代碼，添加一個click事件處理程序調用的preventDefault和stopPropagation若是點擊touchend已經處理用戶抽頭的結果。

易於實施：先進。這種技術須要作更多的工做頁面上的連接添加和維護。對可能發生的事情，而不是一上一下，如縮放或輕掃的手勢，觸摸事件的代碼測試必須是有彈性。

支持SPDY協議

有些折磨網站的性能瓶頸，不管是臺式機或移動，結果在應用層的HTTP和HTTPS協議的低效率。在2009年，谷歌開始工做名爲SPDY（發音爲「迅速」），解決了一些這些限制的替代協議。咱們的目標是使這是一個開源項目，將實施多個瀏覽器和Web服務器，但最初只支持谷歌的Chrome瀏覽器（版本10或更高版本）和谷歌網站上。因爲Web服務器被釋放，實現SPDY，網站將可以使用此協議的任何用戶的瀏覽器支持。在測試執行一組有表明性的前100名互聯網網站25 SPDY，谷歌觀察速度的提升，從27％至60％不等。

SPDY自動使用gzip壓縮的全部內容，並與HTTP不一樣，它也使用gzip的頭數據。SPDY採用複用的技術，使在一個TCP鏈接發送多個數據流請求或響應。此外，SPDY容許請求的優先次序，因此，例如，一個視頻，是中央的頁面的內容能夠被給予更高的優先級比在廣告中顯示的邊緣。

SPDY最革命性創新可能的是，數據流能夠是雙向的，不管是由客戶機或服務器能夠啓動，容許推到客戶端的內容，而不用首先被請求的。例如，當用戶第一次訪問一個網站，並所以不還沒有有任何緩存的內容的網站上，該服務器能夠將響應第一個頁面請求，而不是等待要單獨提出的每一個資源的全部必需的資源。做爲一種替代方法，則服務器能夠向客戶端發送的提示，提示，將須要的資源，但仍然容許在客戶端發起的請求。這仍然是速度不是等待客戶端來解析在網站頁面上，並發現自身的資源需求。

雖然SPDY是不特定的移動平臺，經過移動網絡的可用帶寬有限意味着SPDY優化移動網站支持時，在下降延遲將是特別有用的。

實施的難易程度：中度到重度，取決於在網站上和服務器環境。谷歌已經爲Apache 2.2- mod_spdy提供免費的SPDY模塊，然而，mod_spdy線程模型問題，並無發揮好mod_php，而且默認狀況下，因此這須要額外的注意，以確保其正常運行您的網站。

不要忘了測試！

提醒人們，連續和仔細的測試是必不可少的，沒有討論將是不完整的性能優化。每次改變，你的系統僅僅是一個理論，直到它的測試是針對一個基線。猜想出現性能瓶頸的地方是沒有意義的，除非根據實際測試數據。

偉大的開源和商業工具能夠提供綜合測試，完整的地理分佈和帶寬/延遲節流。此外，朗姆酒（真實用戶監測）工具測試實驗室，進入不可預測的用戶行爲的領域。

支持移動，以及桌面場景的測試選項。若是您選擇的自動化解決方案，必定要選擇一個不斷測試和完善它適用的優化。

性能優化不能有效，若是它僅僅是一個線性發展過程當中的一個步驟。相反，它必須成爲一個持續循環的持續改進的一部分。

參考文獻

1。2009年，L.布斯托斯。分秒必爭;網站性能如何影響購物者的行爲。GetElastic;http://www.getelastic.com/performance/的。

2。鉻項目。SPDY：更快的網絡; https://sites.google.com/a/chromium.org/dev/spdy/spdy-whitepaper一個試驗性協議。

3。動態，T. 2013。案例分析：如何有效的CDN移動遊客。Web性能

4。菲奧拉萬蒂，R. 2011。快速建立移動Web應用程序的按鈕。谷歌開發http://code.google.com/mobile/articles/fast_buttons.html。

5。2006年，G.林登。在Web 2.0瑪麗莎梅耶。Geeking與格雷格http://glinden.blogspot.com/2006/11/marissa-mayer-at-Web-20.html的。

6。國防部SPDY http://code.google.com/p/mod-spdy/的。

7。PhoCusWright的。2010。PhoCusWright的旅遊網站/ Akamai的研究

8。RADWARE。2011年 從移動前沿案例研究：更快的移動網站和業務KPI之間的關係;的http://www.strangeloopnetworks.com/resources/research/state-of-mobile-ecommerce-performance/。

9。比克斯比，J. 2012。2012年國家移動電子商務

10。TEALEAF。2011年 在移動客戶體驗報告。根據哈里斯互動2011年移動交易調查。

11。W3C。2012年 網絡信息的API; http://www.w3.org/TR/netinfo-api/。

12。YUI。ImageLoader的。Yahoo!用戶界面庫; http://yuilibrary.com/yui/docs/imageloader/。