移動網站性能優化：網頁加載技術概覽

性能一直是網站成功的關鍵。越來越多的研究已經證明，不管是小型電商，還是像沃爾瑪那樣的連鎖店，即使是頁面加載時間方面的細微改善，都可以帶來更多的業務，更多的廣告收入，更多的使用者粘性和更多的客戶滿意度。

在過去幾年，web開發者都是基于改善硬體或者提高帶寬速度來優化使用者體驗。但是最近幾年，爆炸式的移動web浏覽器的使用打破了這個途徑。低帶寬，高延遲，小記憶體，低處理器性能的移動裝置環境，迫使開發者不得不想辦法通過優化前端頁面的性能來滿足使用者的性能預期。

在強調如何解決移動端性能問題上，這篇文章總結了一些前端優化的案例，并且概括了一些加速頁面的方法和政策。

<a target="_blank"></a>

不論你的頁面設計地多麼有趣、漂亮、互動性好，不管是在桌面還是移動裝置上，如果頁面需要花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；但是，這些嘗試并沒有什麼用，當使用者有選擇權的時候，高達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的标準是使用連結來加載外部資源。這使得更容易在伺服器上（或者在cdn上）操作更新這些資源，而不是在每個頁面上修改更新這些資源。根據上文讨論的，這種模式也使得浏覽器能從本地緩存而不是伺服器上擷取資源。

但是對還沒有緩存到浏覽器localstorage的資源來說，這種模式對網站的性能有負面的影響。一般來說，一個頁面需要幾十個單獨的請求來擷取資源進而渲染頁面。是以說，從性能的角度來說，如果一個資源沒有很高的被緩存的幾率的話，最好把它嵌入到頁面的html中（叫inlining），而不是使用連結外部。腳本和樣式是支援内嵌到html中的，但是圖檔和其他的二進制資源其實也是可以通過内嵌包含base64編碼的文本來嵌入到html中的。

内嵌的缺點是頁面的大小會變得非常大，是以對于web應用來說，關鍵的是能夠跟蹤分析這個資源什麼時候需要從服務端擷取，什麼時候已經緩存到用戶端了。另外，在第一次請求資源後必須能夠使用代碼在用戶端緩存資源，是以，在移動裝置上，使用html5 localstorage能很好地做到内嵌。

實作小貼士：平穩處理。由于不知道使用者是否已經通路過這個頁面了，是以需要網站有機制能生成不同版本的頁面。

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包括了一些新的結構元素，例如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”。為了減少頁面加載後需要重新通路的内容，可以将圖檔替換為正确的高寬所标記的标簽。

實作小貼士：平穩處理。一些好的javascript庫可以用來處理這些below-the-fold 延遲加載的圖像。^12

在一些移動裝置上，解析javascript代碼的速度能達到100毫秒每千位元組。許多腳本的庫直到頁面被渲染以後都是不需要的加載的。下載下傳和解析這些腳本可以很安全地被推遲到onload事件之後來做。例如，一些需要使用者互動的行為，比如托和拽，都不大可能在使用者看到頁面之前被調用。相同的邏輯也可以應用在腳本執行上面。盡量将腳本的執行延遲到onload事件之後，而不是在初始化頁面中重要的可被使用者看到的内容的時候執行。

這些延遲的腳本可能是你自己寫的，更重要的是，也有可能是第三方的。對廣告、社交媒體部件、或者分析的差勁的腳本優化會導緻阻塞頁面的渲染，會增加珍貴的加載時間。當然，你需要小心地評估諸如jquery這樣為移動網站設計的大型腳本架構，特别當你僅僅隻是使用這些架構中的一些對象的時候更要小心評估。

實作小貼士：平穩處理。許多第三方的架構現在提供延遲加載的異步版本的api。開發者隻需要将原先的邏輯轉化到這個異步版本。一些javascript要做延遲加載會有些複雜，因為在onload之後執行這些腳本需要注意很多注意事項。（例如，你有個腳本需要綁定到onload事件上，你需要做什麼？如果你将腳本延遲到onload事件之後，就一定就會失去很多執行的時機。）

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是使用多個線程并發執行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很适合那種需要背景計算和處理的工作。

在觸摸屏裝置上，當一個使用者觸碰螢幕的時候，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的還有可能是縮放或者敲擊動作。

應用層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）工具能将測試環境從實驗室變成不可預測的真實使用者行為。

觀察移動裝置的測試選擇和桌面場景一樣。如果你在選擇一個自動化的解決方案，請確定使用一個能持續測試，并且能區分出應用優化方法前後的變化的解決方案。

如果性能優化如果隻是在發展過程中的一個步驟而已，它不會有什麼效果的。它必須成為一個持續改善網站的一部分。

 原文釋出時間為：2013-09-01

本文來自雲栖社群合作夥伴“linux中國”