性能一直是網(wǎng)站成功的關(guān)鍵。越來(lái)越多的研究已經(jīng)證明，不管是小型電商，還是像沃爾瑪那樣的連鎖店，即使是頁(yè)面加載時(shí)間方面的細(xì)微改善，都可以帶來(lái)更多的業(yè)務(wù)，更多的廣告收入，更多的用戶粘性和更多的客戶滿意度。

在過(guò)去幾年，Web開(kāi)發(fā)者都是基于改善硬件或者提高帶寬速度來(lái)優(yōu)化用戶體驗(yàn)。但是最近幾年，爆炸式的移動(dòng)Web瀏覽器的使用打破了這個(gè)途徑。低帶寬，高延遲，小內(nèi)存，低處理器性能的移動(dòng)設(shè)備環(huán)境，迫使開(kāi)發(fā)者不得不想辦法通過(guò)優(yōu)化前端頁(yè)面的性能來(lái)滿足用戶的性能預(yù)期。

在強(qiáng)調(diào)如何解決移動(dòng)端性能問(wèn)題上，這篇文章總結(jié)了一些前端優(yōu)化的案例，并且概括了一些加速頁(yè)面的方法和策略。

為什么性能會(huì)影響這么多

不論你的頁(yè)面設(shè)計(jì)地多么有趣、漂亮、交互性好，不管是在桌面還是移動(dòng)設(shè)備上，如果頁(yè)面需要花2到3秒時(shí)間去渲染展示，那么用戶都會(huì)很快變得不耐煩的。可以預(yù)期的是，在頁(yè)面還在加載的時(shí)候，用戶很有可能從瀏覽購(gòu)買的行為轉(zhuǎn)變?yōu)辄c(diǎn)擊回退鍵或者是關(guān)閉瀏覽器的行為。

不到1秒鐘的延遲甚至也會(huì)顯著地影響收入。在2006年，當(dāng)時(shí)還在Google工作的Marissa Mayer說(shuō)，由于用戶表示希望在一個(gè)搜索頁(yè)上看到多于10個(gè)搜索結(jié)果，Google就實(shí)驗(yàn)性地修改為30個(gè)。但是讓人吃驚的是，在這個(gè)實(shí)驗(yàn)里，流量和投 資都減少了20個(gè)百分點(diǎn)，顯然是由于更多的搜索結(jié)果導(dǎo)致多花費(fèi)了半秒時(shí)間來(lái)加載頁(yè)面。^5

用戶的期望總是在不斷的提升。2009年，F(xiàn)orrester研究所的Akamai的一項(xiàng)研究發(fā)現(xiàn)表明，網(wǎng)頁(yè)響應(yīng)時(shí)間可容忍的閥值是2秒，一旦網(wǎng)頁(yè) 相應(yīng)時(shí)間超過(guò)3秒，會(huì)有40%的用戶放棄瀏覽頁(yè)面。一年之后，Akamai的另一項(xiàng)研究表明，超過(guò)3秒放棄瀏覽頁(yè)面的用戶比例上升到了57%。^1,7

此外，移動(dòng)端的用戶希望移動(dòng)設(shè)備上的頁(yè)面性能不亞于桌面PC。由Tealeaf科技（現(xiàn)在已經(jīng)并入IBM）委托的“Harris的互動(dòng)2011移動(dòng) 交互調(diào)查”顯示，在前一年有過(guò)移動(dòng)消費(fèi)經(jīng)歷的成年人中，有85%希望移動(dòng)設(shè)備上的體驗(yàn)?zāi)芘c手提電腦或者PC上的體驗(yàn)相當(dāng)，甚至于更好。并且有63%的人表 示，一旦他在移動(dòng)設(shè)備上的交易遇到了一個(gè)問(wèn)題，他們就不會(huì)再想通過(guò)其他渠道去購(gòu)買這個(gè)公司的其他產(chǎn)品了。^10換句話說(shuō)，差勁的移動(dòng)頁(yè)面性能會(huì)影響到公司 其他各種平臺(tái)的銷售，這其中當(dāng)然也包括線下的實(shí)體店。

移動(dòng)流量正在迅速增長(zhǎng)。對(duì)許多消費(fèi)者而言，他們的手機(jī)或者平板設(shè)備已經(jīng)成為他們?yōu)g覽網(wǎng)絡(luò)的主要入口了，但是其性能表現(xiàn)卻差強(qiáng)人意。2011年2 月，Compuware公司委托Equation 研究所做的一項(xiàng)研究表明，幾乎一半的移動(dòng)用戶（46%）表示他們手機(jī)上的網(wǎng)站加載速度過(guò)慢。60%的用戶希望頁(yè)面能在3秒或者更少的時(shí)間內(nèi)加載完 成，74%的用戶表示，當(dāng)單個(gè)頁(yè)面加載時(shí)間花費(fèi)5秒或者更多的時(shí)候，他們會(huì)選擇離開(kāi)這個(gè)頁(yè)面。在2012年，由Strangeloop網(wǎng)絡(luò)（現(xiàn)已并入 Redware）發(fā)起的一項(xiàng)針對(duì)200家領(lǐng)先的電子商務(wù)網(wǎng)站研究表明，3G網(wǎng)絡(luò)環(huán)境下，平均加載時(shí)間為11.8秒（圖1），而在LTE（4G）環(huán)境下，加 載時(shí)間只有輕微的改善，為8.5秒。

移動(dòng)設(shè)備表現(xiàn)性能的三種影響因素

正如上文所說(shuō)的，移動(dòng)設(shè)備天生有下面三種性能限制：帶寬低，內(nèi)存小，處理器性能低。這些性能挑戰(zhàn)又加上一些其他的問(wèn)題，例如：

網(wǎng)頁(yè)比以前更大。根據(jù)HTTP Archive網(wǎng)站的分析，現(xiàn)在平均的一個(gè)web頁(yè)面需要加載超過(guò)1MB的數(shù)據(jù)，其中包含有圖片，Javascript，CSS（Cascading Style Sheets）等。更大的網(wǎng)頁(yè)會(huì)影響桌面PC的顯示性能。對(duì)于移動(dòng)端的性能 — 特別是3G環(huán)境下的性能 — 影響更嚴(yán)重。這個(gè)影響會(huì)在今后的三年更加明顯。以現(xiàn)在的頁(yè)面增長(zhǎng)速度來(lái)說(shuō)，到2015年，平均的頁(yè)面大小會(huì)達(dá)到2MB。

延遲相差巨大。對(duì)LTE來(lái)說(shuō)，延遲大概有34ms，對(duì)3G來(lái)說(shuō)，延遲大概有350毫秒甚至更多。移動(dòng)端的延遲性 唯一不變的就是延遲時(shí)間永遠(yuǎn)是不定的，即使是在同一個(gè)地點(diǎn)，每次的延遲都是不定的。這是由于大量的數(shù)據(jù)是通過(guò)信息塔進(jìn)行傳輸?shù)摹Ｒ虼酥T如天氣，甚至是持有 者所面向的方向都有可能成為影響因素。

下載速度相差巨大。下載速度的范圍從3G環(huán)境下的1Mbps到LTE環(huán)境下的31Mbps。把這個(gè)和美國(guó)平均的帶寬15Mbps相比是一個(gè)很有意思的事情，3G環(huán)境比平均帶寬慢了15倍，而LTE卻能達(dá)到平均帶寬的2倍那么快。

M.SITES并不能完全解決移動(dòng)端性能的問(wèn)題。

許多網(wǎng)站建設(shè)者嘗試針對(duì)多用戶訪問(wèn)，大網(wǎng)頁(yè)和低流量連接的訪問(wèn)頁(yè)面，開(kāi)發(fā)出短小，快速，精簡(jiǎn)的m.sites；但是，這些嘗試并沒(méi)有什么用，當(dāng)用戶有選擇權(quán)的時(shí)候，高達(dá)35%的移動(dòng)用戶會(huì)選擇瀏覽完整的網(wǎng)站。

這些選擇瀏覽完整網(wǎng)站的用戶顯然比瀏覽m.sites的用戶更有購(gòu)買欲望。一個(gè)研究表明，移動(dòng)端每$7.00的消費(fèi)中，有$5.50是來(lái)自于網(wǎng)站的網(wǎng)站瀏覽，只有$1.00是來(lái)自于m.sites，剩下的$0.50則是來(lái)自于客戶端。

解決問(wèn)題

改善網(wǎng)站性能的主要策略并沒(méi)有因?yàn)閺腜C變成手機(jī)或者平板設(shè)備而有變化，只是會(huì)參雜一些小的策略。

不論在PC還是在移動(dòng)瀏覽器上，頁(yè)面展示需要的時(shí)間里，只有20%是用來(lái)讀取頁(yè)面的HTML的。剩下的80%是用來(lái)加載額外的像樣式表、腳本文件、或者圖片這樣的資源和執(zhí)行客戶端的程序。

三個(gè)主要的改善性能的策略是：

• 減少每個(gè)頁(yè)面需要獲取額外資源的HTTP請(qǐng)求數(shù)
• 減少每個(gè)請(qǐng)求加載的大小
• 優(yōu)化客戶端執(zhí)行的優(yōu)先級(jí)和腳本執(zhí)行的效率

由于移動(dòng)網(wǎng)絡(luò)通常比桌面機(jī)器的網(wǎng)絡(luò)慢，所以減少請(qǐng)求數(shù)和請(qǐng)求加載量是非常重要的。由于移動(dòng)端的瀏覽器解析HTML和執(zhí)行JavaScript的效率 比桌面PC低，所以優(yōu)化客戶端程序也是非常關(guān)鍵的。另外，移動(dòng)端瀏覽器的緩存大小比桌面PC低，所以需要有方法能重復(fù)利用本地的緩存資源。

文章剩余部分總結(jié)了能解決這些問(wèn)題的方法。雖然這些方法大都可以自動(dòng)化解決，當(dāng)然也可以由有經(jīng)驗(yàn)的前端工程師來(lái)手動(dòng)解決。關(guān)鍵就是要知道人工解決這 些技術(shù)的方法如何控制資源的請(qǐng)求。通常在CMS（內(nèi)容管理系統(tǒng)）或者其他Web應(yīng)用中，有些頁(yè)面包含一些自動(dòng)生成好的或者離線的HTML片段、CSS或者 Javascript文件，這樣的頁(yè)面開(kāi)發(fā)者就不需要去優(yōu)化它們了。

減少請(qǐng)求

最大的性能漏洞就是一個(gè)頁(yè)面需要發(fā)起幾十個(gè)網(wǎng)絡(luò)請(qǐng)求來(lái)獲取諸如樣式表、腳本或者圖片這樣的資源。這個(gè)在相對(duì)低帶寬和高延遲的移動(dòng)設(shè)備連接上來(lái)說(shuō)影響 更嚴(yán)重。CDNs（內(nèi)容分發(fā)網(wǎng)絡(luò)）把資源放在離用戶地理位置更近的地方對(duì)解決這個(gè)問(wèn)題能起到很大作用，但是比起獲取請(qǐng)求，大量的請(qǐng)求對(duì)頁(yè)面加載時(shí)間的影響 更為嚴(yán)重。而且最近的發(fā)現(xiàn)表明，CDNs對(duì)移動(dòng)端用戶的性能影響越來(lái)越低。

下面的章節(jié)討論了簡(jiǎn)化HTTP請(qǐng)求的幾種方法。

整合資源

對(duì)開(kāi)發(fā)者來(lái)說(shuō)，將Javascript代碼和CSS樣式放到公共的文件中供多個(gè)頁(yè)面共享是一種標(biāo)準(zhǔn)的優(yōu)化方法。這個(gè)方法能很簡(jiǎn)單的維護(hù)代碼，并且提高客戶端緩存的使用效率。

在Javascript文件中，要確保在一個(gè)頁(yè)面中相同的腳本不會(huì)被加載多次。當(dāng)大團(tuán)隊(duì)或者多個(gè)團(tuán)隊(duì)合作開(kāi)發(fā)的時(shí)候，這種冗余的腳本就很容易出現(xiàn)。你可能會(huì)對(duì)它的發(fā)生頻率并不低感到非常吃驚。

Sprites是css中處理圖片的一項(xiàng)技術(shù)。Sprites就是將多張圖片整合到一個(gè)線性的網(wǎng)狀的大圖片中。頁(yè)面就可以將這個(gè)大圖片一次性獲取回 來(lái)并且做為css的背景圖，然后使用css的背景定位屬性展示頁(yè)面需要的圖片部分。這種技術(shù)將多個(gè)請(qǐng)求整合成一個(gè)，能顯著地改善性能。

實(shí)現(xiàn)小貼士：平穩(wěn)地改進(jìn)但是需要對(duì)資源有控制權(quán)限。根據(jù)開(kāi)發(fā)者的網(wǎng)站不同權(quán)限，一些資源并不需要被整合起來(lái)（例如，一些由CMS生成的資源）。還 有，對(duì)于一些外部域引用的資源，強(qiáng)行整合可能會(huì)導(dǎo)致問(wèn)題。需要注意的是，整合資源對(duì)手機(jī)瀏覽器來(lái)說(shuō)是一把雙刃劍。整合資源確實(shí)會(huì)在首次訪問(wèn)減少請(qǐng)求，但是 大的資源文件可能會(huì)導(dǎo)致緩存失效，所以，需要小心地使用各種技術(shù)整合資源，以達(dá)到優(yōu)化本地存儲(chǔ)的目的。

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

現(xiàn)在所有的瀏覽器都會(huì)使用本地資源去緩存住那些被Cache-Control或者Expires頭標(biāo)記的資源，這些頭能標(biāo)記資源需要緩存的時(shí)間。另 外，ETag（實(shí)體標(biāo)簽）和Last-Modified頭來(lái)標(biāo)識(shí)當(dāng)資源過(guò)期后是否需要重新請(qǐng)求。瀏覽器為了減少不必要的服務(wù)器請(qǐng)求，盡可能地從本地緩存中 獲取資源，并且將那些已經(jīng)過(guò)期的、或者當(dāng)緩存空間減小的時(shí)候?qū)⒛切┖芫貌挥玫馁Y源進(jìn)行清理。瀏覽器緩存通常包括圖片，CSS，Javascript代碼， 這些緩存能合理地提高網(wǎng)站的性能。（比如為了支持后退和前進(jìn)的按鈕，使用一個(gè)單獨(dú)的緩存來(lái)保存整個(gè)渲染的頁(yè)面）。

移動(dòng)瀏覽器緩存，通常是比桌面PC小的多，這就導(dǎo)致了緩存的數(shù)據(jù)會(huì)很經(jīng)常被清理。HTML5的緩存基于瀏覽器緩存提供了一個(gè)很好的替換方案。 Javascript的localStorage已經(jīng)在所有主流的桌面和移動(dòng)端瀏覽器上都實(shí)現(xiàn)了。使用腳本代碼能簡(jiǎn)便地支持HTML5的 localStorage操作，可以讀寫鍵值數(shù)據(jù)，每個(gè)域名大概有5MB的容量。雖然不同的移動(dòng)瀏覽器上讀寫速度相差很大，但是localStorage 大容量的緩存使得它很適合作為客戶端的緩存。從localStorage獲取資源明顯快于從服務(wù)器上獲取資源，而且在大多數(shù)移動(dòng)設(shè)備上也比依靠緩存頭或者 瀏覽器的本地緩存更靈活可靠。這是移動(dòng)瀏覽器比桌面PC更有優(yōu)勢(shì)的一個(gè)地方，在桌面PC上，本地緩存仍然優(yōu)先使用標(biāo)準(zhǔn)的瀏覽器緩存，導(dǎo)致桌面PC本地緩存 的性能落后于移動(dòng)瀏覽器。

實(shí)現(xiàn)小貼士：需要進(jìn)一步考慮。雖然localStorage的機(jī)制易于實(shí)現(xiàn)，但是它的一些控制機(jī)制卻是非常復(fù)雜的。你需要考慮到緩存帶給你的所有問(wèn)題，比如緩存失效（什么時(shí)候需要?jiǎng)h除緩存？），緩存丟失（當(dāng)你希望數(shù)據(jù)在緩存中的時(shí)候它并不在怎么辦？），還有當(dāng)緩存滿的時(shí)候你怎么辦？

首次使用的時(shí)候在HTML中嵌入資源

HTML的標(biāo)準(zhǔn)是使用鏈接來(lái)加載外部資源。這使得更容易在服務(wù)器上（或者在CDN上）操作更新這些資源，而不是在每個(gè)頁(yè)面上修改更新這些資源。根據(jù)上文討論的，這種模式也使得瀏覽器能從本地緩存而不是服務(wù)器上獲取資源。

但是對(duì)還沒(méi)有緩存到瀏覽器localStorage的資源來(lái)說(shuō)，這種模式對(duì)網(wǎng)站的性能有負(fù)面的影響。一般來(lái)說(shuō)，一個(gè)頁(yè)面需要幾十個(gè)單獨(dú)的請(qǐng)求來(lái)獲取 資源從而渲染頁(yè)面。所以說(shuō)，從性能的角度來(lái)說(shuō)，如果一個(gè)資源沒(méi)有很高的被緩存的幾率的話，最好把它嵌入到頁(yè)面的HTML中（叫inlining），而不是 使用鏈接外部。腳本和樣式是支持內(nèi)嵌到HTML中的，但是圖片和其他的二進(jìn)制資源其實(shí)也是可以通過(guò)內(nèi)嵌包含base64編碼的文本來(lái)嵌入到HTML中的。

內(nèi)嵌的缺點(diǎn)是頁(yè)面的大小會(huì)變得非常大，所以對(duì)于Web應(yīng)用來(lái)說(shuō)，關(guān)鍵的是能夠跟蹤分析這個(gè)資源什么時(shí)候需要從服務(wù)端獲取，什么時(shí)候已經(jīng)緩存到客戶端 了。另外，在第一次請(qǐng)求資源后必須能夠使用代碼在客戶端緩存資源，因此，在移動(dòng)設(shè)備上，使用HTML5 localStorage能很好地做到內(nèi)嵌。

實(shí)現(xiàn)小貼士：平穩(wěn)處理。由于不知道用戶是否已經(jīng)訪問(wèn)過(guò)這個(gè)頁(yè)面了，所以需要網(wǎng)站有機(jī)制能生成不同版本的頁(yè)面。

使用HTML5服務(wù)端發(fā)送事件

Web應(yīng)用已經(jīng)使用了各種從服務(wù)器上輪詢資源的方法來(lái)持續(xù)地更新頁(yè)面。HTML5的EventSource對(duì)象和Server-Sent事件能通過(guò) 瀏覽器端的JavaScript代碼打開(kāi)一個(gè)服務(wù)端連接客戶端的單向通道。服務(wù)端可以使用這個(gè)寫通道來(lái)發(fā)送數(shù)據(jù)，這樣能節(jié)省了HTTP創(chuàng)建多個(gè)輪詢請(qǐng)求的 消耗。這種方式比HTML的WebSocket更高效。WebSocket的使用場(chǎng)景是，當(dāng)有許多客戶端和服務(wù)端的交互的時(shí)候（比如消息或者游戲），在全 雙工連接上建立一個(gè)雙向通道。

實(shí)現(xiàn)小貼士：需要進(jìn)一步考慮。這個(gè)技術(shù)是基于具體的技術(shù)實(shí)現(xiàn)的。如果你的網(wǎng)站當(dāng)前是使用其他的Ajax或者Comet技術(shù)來(lái)輪詢的，轉(zhuǎn)變成Server-Sent 事件需要重構(gòu)網(wǎng)站的Javascript代碼。

消除重定向

當(dāng)用戶在一個(gè)移動(dòng)設(shè)備上訪問(wèn)桌面PC網(wǎng)站的時(shí)候，Web網(wǎng)站應(yīng)用通常讀取HTTP的user-agent頭來(lái)判斷這個(gè)用戶是否是來(lái)自移動(dòng)設(shè)備的。然 后應(yīng)用會(huì)發(fā)送帶有空HTTP body和重定向HTTP地址頭的HTTP 301（或者302）請(qǐng)求，把用戶重定向到網(wǎng)站的移動(dòng)版本上去。但是，這個(gè)額外的客戶端和服務(wù)端的交互通常在移動(dòng)網(wǎng)絡(luò)上會(huì)消耗幾百毫秒。因此，在原先的請(qǐng) 求上傳遞移動(dòng)的web頁(yè)會(huì)比傳遞一個(gè)重定向的信息并讓客戶端再請(qǐng)求移動(dòng)頁(yè)面更快。

對(duì)于那些想要在移動(dòng)設(shè)備上看桌面PC網(wǎng)站的用戶來(lái)說(shuō)，你可以在移動(dòng)web頁(yè)面上提供一個(gè)鏈接入口，這樣也能同時(shí)表示你的網(wǎng)站是并不提倡這種行為的。

實(shí)現(xiàn)小貼士：雖然這個(gè)技術(shù)在理論上是簡(jiǎn)單的，但是實(shí)際上并不易于實(shí)施。由于有些m.sites是宿主在其他地方 的，所以許多網(wǎng)站會(huì)選擇重定向到一個(gè)不同的服務(wù)器上。有的網(wǎng)站則是會(huì)在重定向請(qǐng)求的時(shí)候種植上Cookie告訴Web應(yīng)用這個(gè)用戶是在使用移動(dòng)設(shè)備。這種 方法可能對(duì)web應(yīng)用來(lái)說(shuō)更容易控制。

減少資源負(fù)載

大小問(wèn)題。渲染小頁(yè)面更快，獲取小資源也更快。減小每個(gè)請(qǐng)求的大小通常不如減少頁(yè)面請(qǐng)求個(gè)數(shù)那么顯著地提高性能。但是，有些技術(shù)在性能方面，特別是在需要對(duì)帶寬和處理器性能精打細(xì)算的移動(dòng)設(shè)備環(huán)境下，仍然是能帶來(lái)很大利益的。

壓縮文本和圖像

諸如gzip這樣的壓縮技術(shù)，依靠增加服務(wù)端壓縮和瀏覽器解壓的步驟，來(lái)減少資源的負(fù)載。但是，一般來(lái)說(shuō)，這些操作都是被高度優(yōu)化過(guò)了。而且測(cè)試表 明，壓縮對(duì)網(wǎng)站還是起到優(yōu)化性能的作用的。那些基于文本的響應(yīng)，包括HTML，XML，JSON（Javascript Object Notation），Javascript，和CSS可以減少大約70%的大小。

瀏覽器在Accept-Encoding請(qǐng)求頭中申明它的解壓縮技術(shù)，并且當(dāng)它們接收到服務(wù)端返回的Content-Encoding響應(yīng)頭標(biāo)示的時(shí)候，就會(huì)按照這個(gè)響應(yīng)頭自動(dòng)做解壓操作。

實(shí)現(xiàn)小貼士：易于實(shí)現(xiàn)。如果設(shè)置正確的話，現(xiàn)在所有的Web服務(wù)器都支持壓縮響應(yīng)。但是，也有一些桌面PC的安全工具會(huì)將請(qǐng)求頭中的Accept-Encoding頭去掉，這樣即使瀏覽器支持解壓縮，用戶也無(wú)法獲取到壓縮后的響應(yīng)。

代碼簡(jiǎn)化

簡(jiǎn)化通常是使用在腳本和樣式文件中，刪除一些不必要的字符，比如空格，換行符，或者注釋等。不需要暴露給外部的命名就可以被縮短為一個(gè)或者兩個(gè)字 符，比如變量名。合適的簡(jiǎn)化資源通常在客戶端不需要做任何其他的處理，并且平均減少20%的資源大小。內(nèi)嵌在HTML中的腳本和樣式文件也是可以精簡(jiǎn)的。 有很多很好的庫(kù)來(lái)做精簡(jiǎn)化的操作，這些庫(kù)一般也同時(shí)會(huì)提供合并多個(gè)文件這樣減少請(qǐng)求數(shù)的服務(wù)。

簡(jiǎn)化帶來(lái)的好處并不局限于減少帶寬和延遲，對(duì)于那些移動(dòng)設(shè)備上緩存無(wú)法保存的過(guò)大資源來(lái)說(shuō)，也是很有改善的。Gzip在這個(gè)方面并沒(méi)有任何幫助，因?yàn)橘Y源是在被解壓后才被緩存起來(lái)的。

實(shí)現(xiàn)小貼士：易于實(shí)現(xiàn)。Google的Closure Compiler已經(jīng)難以置信地完成了理解和簡(jiǎn)化Javascript的工作。但是CSS的簡(jiǎn)化則沒(méi)有那么容易，因?yàn)閷?duì)不同瀏覽器來(lái)說(shuō)有不同的CSS技術(shù) 能迷惑CSS簡(jiǎn)化工具，然后讓CSS簡(jiǎn)化后無(wú)法正常工作。必須要注意的是，已經(jīng)有這樣的案例了，即使只是刪除了不必要的字符，簡(jiǎn)化工作也有可能破壞頁(yè)面。 所以當(dāng)你應(yīng)用簡(jiǎn)化技術(shù)之后，請(qǐng)做一下完整的功能測(cè)試工作。

調(diào)整圖片大小

圖片通常是占用了Web頁(yè)面加載的大部分網(wǎng)絡(luò)資源，也占用了頁(yè)面緩存的主要空間。小屏幕的移動(dòng)設(shè)備提供了通過(guò)調(diào)整圖片大小來(lái)加速傳輸和渲染圖片資源的機(jī)會(huì)。如果用戶只是在小的移動(dòng)瀏覽器窗口中看圖片的話，高分辨率的圖片就會(huì)浪費(fèi)帶寬、處理時(shí)間和緩存空間。

為了加速頁(yè)面渲染速度和減少帶寬及內(nèi)存消耗，可以動(dòng)態(tài)地調(diào)整圖片大小或者將圖片替換為移動(dòng)設(shè)備專用的更小的版本。不要依靠瀏覽器來(lái)將高分辨率的圖片轉(zhuǎn)換成小尺寸的圖片，這樣會(huì)浪費(fèi)帶寬。

另外一個(gè)方法是先盡快加載一個(gè)低分辨率的圖片來(lái)渲染頁(yè)面，在onload或者用戶已經(jīng)開(kāi)始和頁(yè)面交互以后將這些低分辨率的圖片替換成為高分辨率的圖片。

實(shí)現(xiàn)小貼士：特別應(yīng)用在高度動(dòng)態(tài)化的網(wǎng)站是有優(yōu)勢(shì)的。

使用HTML5和CSS 3.0來(lái)簡(jiǎn)化頁(yè)面

HTML5包括了一些新的結(jié)構(gòu)元素，例如header，nav，article和footer。使用這些語(yǔ)義化的元素比傳統(tǒng)的使用div和span 標(biāo)簽?zāi)苁沟庙?yè)面更簡(jiǎn)單和更容易解析。一個(gè)簡(jiǎn)單的頁(yè)面更小加載更快，并且簡(jiǎn)單的DOM（Document Object Model）代表著更快的JavaScript執(zhí)行效率。新的標(biāo)簽?zāi)芎芸斓貞?yīng)用在包括移動(dòng)端的新瀏覽器版本上，并且HTML5設(shè)計(jì)讓那些不支持它的瀏覽器 能平穩(wěn)過(guò)渡使用新標(biāo)簽。

HTML5的一些表單元素提供了許多新屬性來(lái)完成原本需要javascript來(lái)完成的功能。例如，新的placeholder屬性用于顯示在用戶輸入進(jìn)入輸入框之前顯示的介紹性文字，autofocus屬性用于標(biāo)示哪個(gè)輸入框應(yīng)當(dāng)被自動(dòng)定位。

也有一些新的輸入框元素能不用依靠Javascript就可以完成一些通用的需求。這些新的輸入框類型包括像e-mail，URL，數(shù)字，范圍，日 期和時(shí)間這樣需要復(fù)雜的用戶交互和輸入驗(yàn)證的元素。在移動(dòng)瀏覽器上，當(dāng)需要輸入文本的時(shí)候，彈出的鍵盤通常是由特定的輸入框類型來(lái)做選擇的。不支持指定的 輸入類型的瀏覽器就會(huì)只顯示一個(gè)文本框。

另外，只要瀏覽器支持內(nèi)建的層次，圓角，陰影，動(dòng)畫，過(guò)渡和其他的圖片效果，CSS 3.0就能幫助你創(chuàng)建輕便簡(jiǎn)易的頁(yè)面了，而這些圖片效果原先是需要加載圖片才能完成的。這樣，這些新特性就能加速頁(yè)面渲染了。

有很多Web站點(diǎn)都提供哪些移動(dòng)或者桌面瀏覽器支持哪項(xiàng)性能的更新說(shuō)明。（例如：http://caniuse.com/ 和 mobilehtml5.org）。

實(shí)現(xiàn)小貼士：需要進(jìn)一步考慮。人工地做這些改動(dòng)是非常復(fù)雜和耗時(shí)的。如果你使用CMS，它可以幫你生成許多你不需要控制的HTML和CSS。

優(yōu)化客戶端的程序處理

瀏覽器按照什么順序來(lái)執(zhí)行代碼生成一個(gè)頁(yè)面，和頁(yè)面復(fù)雜性及JavaScript的技術(shù)選擇，都對(duì)性能有很大的影響。特別在客戶端相對(duì)較慢的CPUs和少內(nèi)存的移動(dòng)端中尤為明顯。下面的章節(jié)提供一些策略來(lái)提升頁(yè)面處理的性能。

延遲渲染”BELOW-THE-FOLD”內(nèi)容

可以確定的是如果我們將不可見(jiàn)區(qū)域的內(nèi)容延遲加載，那么頁(yè)面就會(huì)更快地展現(xiàn)在用戶面前，這個(gè)區(qū)域叫做”below the fold”。為了減少頁(yè)面加載后需要重新訪問(wèn)的內(nèi)容，可以將圖片替換為正確的高寬所標(biāo)記的<img>標(biāo)簽。

實(shí)現(xiàn)小貼士：平穩(wěn)處理。一些好的Javascript庫(kù)可以用來(lái)處理這些below-the-fold 延遲加載的圖像。

延遲讀取和執(zhí)行的腳本

在一些移動(dòng)設(shè)備上，解析Javascript代碼的速度能達(dá)到100毫秒每千字節(jié)。許多腳本的庫(kù)直到頁(yè)面被渲染以后都是不需要的加載的。下載和解析 這些腳本可以很安全地被推遲到onload事件之后來(lái)做。例如，一些需要用戶交互的行為，比如托和拽，都不大可能在用戶看到頁(yè)面之前被調(diào)用。相同的邏輯也 可以應(yīng)用在腳本執(zhí)行上面。盡量將腳本的執(zhí)行延遲到onload事件之后，而不是在初始化頁(yè)面中重要的可被用戶看到的內(nèi)容的時(shí)候執(zhí)行。

這些延遲的腳本可能是你自己寫的，更重要的是，也有可能是第三方的。對(duì)廣告、社交媒體部件、或者分析的差勁的腳本優(yōu)化會(huì)導(dǎo)致阻塞頁(yè)面的渲染，會(huì)增加 珍貴的加載時(shí)間。當(dāng)然，你需要小心地評(píng)估諸如jquery這樣為移動(dòng)網(wǎng)站設(shè)計(jì)的大型腳本框架，特別當(dāng)你僅僅只是使用這些框架中的一些對(duì)象的時(shí)候更要小心評(píng) 估。

實(shí)現(xiàn)小貼士：平穩(wěn)處理。許多第三方的框架現(xiàn)在提供延遲加載的異步版本的API。開(kāi)發(fā)者只需要將原先的邏輯轉(zhuǎn)化到 這個(gè)異步版本。一些JavaScript要做延遲加載會(huì)有些復(fù)雜，因?yàn)樵趏nload之后執(zhí)行這些腳本需要注意很多注意事項(xiàng)。（例如，你有個(gè)腳本需要綁定 到onload事件上，你需要做什么？如果你將腳本延遲到onload事件之后，就一定就會(huì)失去很多執(zhí)行的時(shí)機(jī)。）

使用Ajax來(lái)增強(qiáng)進(jìn)程

Ajax（Asynchronous JavaScript and XML）是一項(xiàng)使用XHR（XMLHttpRequest）對(duì)象來(lái)從Web服務(wù)器上獲取數(shù)據(jù)的技術(shù)，它并不需要更新正在運(yùn)行的頁(yè)面。Ajax能更新頁(yè)面上 的某個(gè)部分而不需要重新構(gòu)建整個(gè)頁(yè)面。它通常用來(lái)提交用戶的交互相應(yīng)，但是也可以用來(lái)先加載頁(yè)面的框架部分，然后當(dāng)用戶準(zhǔn)備好瀏覽網(wǎng)頁(yè)的時(shí)候再填充詳細(xì)的 內(nèi)容。

盡管是這個(gè)名字，但是XMLHttpRequest并不強(qiáng)制要求你只能使用XML。你可以通過(guò)調(diào)用overrideMineType方法來(lái)制 定”application/json”類型來(lái)使用json替換XML。使用JSON.parse會(huì)比使用原生的eval()函數(shù)快了幾乎兩倍，并且更為 安全。

同時(shí)，切記Ajax的返回響應(yīng)也會(huì)得益于那些應(yīng)用在普通的返回響應(yīng)的優(yōu)化技術(shù)上面。確保對(duì)你的Ajax返回響應(yīng)使用了緩存頭，簡(jiǎn)化，gzip壓縮，資源合并等技術(shù)。

實(shí)現(xiàn)小貼士：由于這個(gè)技術(shù)是根據(jù)具體應(yīng)用不同而不同的，所以很難量化。或許由于跨域問(wèn)題，你需要使用XHR2，這個(gè)技術(shù)能使用外部域的資源，從而能進(jìn)行跨域的XHR請(qǐng)求。

根據(jù)網(wǎng)絡(luò)狀況進(jìn)行適配處理

由于使用更多帶寬會(huì)使用更多移動(dòng)網(wǎng)絡(luò)的費(fèi)用，所以只有能檢測(cè)網(wǎng)絡(luò)的類型才能使用針對(duì)特定網(wǎng)絡(luò)的優(yōu)化技術(shù)。例如，預(yù)加載未來(lái)使用到的請(qǐng)求是非常聰明的做法，但是如果用戶的帶寬很稀有，并且加載的有些資源是永遠(yuǎn)不會(huì)用到的話，這個(gè)技術(shù)就是不合理的了。

在Android 2.2+，navigator.connection.type屬性的返回值能讓你區(qū)分Wifi和2G/3G/4G網(wǎng)絡(luò)。在Blackberry 上，blackberry.network也能提供相似的信息。另外，服務(wù)端通過(guò)檢測(cè)請(qǐng)求中的User-Agent頭或者其他的嵌入到請(qǐng)求中的信息能讓你 的應(yīng)用檢測(cè)到網(wǎng)絡(luò)狀況。

實(shí)現(xiàn)小貼士：需要進(jìn)一步考慮。檢測(cè)網(wǎng)絡(luò)信息的API最近已經(jīng)有所變化了。^11 接口現(xiàn)在不是直接定義Wi-Fi，3G等網(wǎng)絡(luò)狀況，而是給出了帶寬信息和諸如“非常慢，慢，快和非常快”這樣的建議。有個(gè)屬性能給出估計(jì)的MB/s值和一 個(gè)“meterd”的Boolean值來(lái)表示它的可信度，但是對(duì)瀏覽器來(lái)說(shuō)，很難根據(jù)這個(gè)來(lái)判斷環(huán)境。判斷當(dāng)前網(wǎng)絡(luò)環(huán)境然后適配仍然是一種最好的方法，但 是這種方法正在被考慮被替換。

對(duì)多線程來(lái)說(shuō)盡量使用HTML5的WEB WORKER特性

HTML5中的Web Worker是使用多個(gè)線程并發(fā)執(zhí)行Javascript程序。另外，這種特別的多線程實(shí)現(xiàn)能減少困惑開(kāi)發(fā)者多年的，在其他平臺(tái)上遇到的問(wèn)題。例如，當(dāng)一 個(gè)線程需要改變一個(gè)正在被其他線程使用的資源該如何處理。在Web Worker中，子線程不能修改主用戶界面（UI）線程使用的資源。

對(duì)提高移動(dòng)站點(diǎn)的性能來(lái)說(shuō)，Web Worker中的代碼很適合用來(lái)預(yù)處理用戶完成進(jìn)一步操作所需要的資源的，特別是在用戶的帶寬資源不緊缺的情況下。在低處理器性能的移動(dòng)設(shè)備上，過(guò)多的預(yù) 加載可能會(huì)干擾當(dāng)前頁(yè)面的UI響應(yīng)。使用多線程代碼，讓W(xué)eb Worker對(duì)象（并且盡可能使用localStorage來(lái)緩存數(shù)據(jù)）在另外一個(gè)線程中操作預(yù)加載資源，這樣就能不影響當(dāng)前的UI表現(xiàn)了。

要特別說(shuō)明的是，Web Worker只在Android 2.0以上的版本實(shí)現(xiàn)，而且iphone上的ios5之前的版本也不支持。在桌面PC上，總是落后的IE只在IE 10才支持Web Worker。

實(shí)現(xiàn)小貼士：平穩(wěn)過(guò)渡。雖然這項(xiàng)技術(shù)并不是非常難實(shí)現(xiàn)，但是對(duì)Web Workers來(lái)說(shuō)，有一些限制需要強(qiáng)制遵守。Web Workers不能進(jìn)入到頁(yè)面的DOM，也不能改變頁(yè)面上的任何東西。Web Worker很適合那種需要后臺(tái)計(jì)算和處理的工作。

將CLICK事件替換成TOUCH事件

在觸摸屏設(shè)備上，當(dāng)一個(gè)用戶觸碰屏幕的時(shí)候，onclick事件并沒(méi)有立即觸發(fā)。設(shè)備會(huì)使用大約半秒（大多數(shù)設(shè)備差不多都是300毫秒）來(lái)讓用戶確 定是手勢(shì)操作還是點(diǎn)擊操作。這個(gè)延遲會(huì)很明顯地影響用戶期望的響應(yīng)性能。要使用touchend事件來(lái)替換才能解決。當(dāng)用戶觸碰屏幕的時(shí)候，這個(gè)事件會(huì)立 即觸發(fā)。

為了要確保不會(huì)產(chǎn)生用戶不期望的行為，你應(yīng)該也要使用touchstart和touchmove事件。例如，除非同時(shí)有個(gè)touchstart事件 在button上，否則不要判斷touchend事件在button上就意味著點(diǎn)擊行為 — 因?yàn)橛脩粲锌赡軓钠渌胤接|碰開(kāi)始，然后拖拽到button上觸碰結(jié)束的。你也可以在touchstart事件之后使用touchmove事件來(lái)避免將 touchend事件誤判為點(diǎn)擊，當(dāng)然前提是需要假設(shè)拖拽的手勢(shì)并不是預(yù)期產(chǎn)生點(diǎn)擊行為。

另外，你也需要去處理onclick事件來(lái)讓瀏覽器改變button的外觀從而標(biāo)識(shí)為已點(diǎn)擊的狀態(tài)，同時(shí)你也需要處理那些不支持touch事件的瀏 覽器。為了避免代碼在touchend和onclick代碼中重復(fù)執(zhí)行，你需要在確保用戶觸碰事件已經(jīng)在touchend執(zhí)行了之后，在click事件中 調(diào)用preventDefault和stopPropagation方法。^4

實(shí)現(xiàn)小貼士：需要進(jìn)一步考慮。這種技術(shù)需要更多工作才能在一個(gè)頁(yè)面中增加和維護(hù)鏈接。touch事件的代碼必須考慮其他手勢(shì)，因?yàn)樘鎿Qclick的還有可能是縮放或者敲擊動(dòng)作。

支持SPDY協(xié)議

應(yīng)用層HTTP和HTTPS協(xié)議導(dǎo)致的一些性能瓶頸，使得不論是桌面還是移動(dòng)端的網(wǎng)站都非常難受。在2009年，谷歌開(kāi)始研發(fā)一種叫做SPDY（諧 意是”speedy”）的協(xié)議來(lái)替換已有的協(xié)議，這種協(xié)議宣稱能突破這些限制。這個(gè)協(xié)議的目標(biāo)是讓多種瀏覽器和多種Web服務(wù)都能支持，所以這個(gè)協(xié)議是開(kāi) 源的，但是初步地，只有Google的Chrome瀏覽器（在版本10及之后的）和google的站點(diǎn)支持。一旦一個(gè)Web服務(wù)支持SPDY，那么它上面 的所有站點(diǎn)都可以和支持這個(gè)協(xié)議的瀏覽器使用SPDY進(jìn)行交互。將SPDY應(yīng)用在25個(gè)top100的Internet網(wǎng)站上，Google收集到的數(shù)據(jù) 是網(wǎng)站的速度會(huì)改善27%到60%不等。^2

SPDY自動(dòng)使用gzip壓縮所有內(nèi)容，和HTTP不同的是，它連header的數(shù)據(jù)也使用gzip壓縮。SPDY使用多線程技術(shù)讓多個(gè)請(qǐng)求流或者響應(yīng)流能共用一個(gè)TCP連接。另外SPDY允許請(qǐng)求設(shè)置優(yōu)先級(jí)，比如，頁(yè)面中心的視頻會(huì)比邊框的廣告擁有更高的優(yōu)先級(jí)。

或許SPDY中最變革性的發(fā)明就是流是雙向的，并且可以由客戶端或者服務(wù)端發(fā)起，這樣能使得信息能推送到客戶端，而不用由客戶端發(fā)起第一次請(qǐng)求。例 如，當(dāng)一個(gè)用戶第一次瀏覽一個(gè)站點(diǎn)，還沒(méi)有任何站點(diǎn)的緩存，這個(gè)時(shí)候服務(wù)端就可以在響應(yīng)中推送所有的請(qǐng)求資源，而不用等候每個(gè)資源被再次獨(dú)立請(qǐng)求了。作為 替換協(xié)議，服務(wù)端可以發(fā)送暗示給客戶端，提示頁(yè)面需要哪些資源，同時(shí)也允許由客戶端來(lái)初始化請(qǐng)求。即使是使用后一種這樣的方式也比讓客戶端解析頁(yè)面然后自 己發(fā)現(xiàn)有哪些資源需要被請(qǐng)求來(lái)得快。

雖然SPDY并沒(méi)有對(duì)移動(dòng)端有什么特別的設(shè)置，但是移動(dòng)端有限的帶寬就使得如果支持SPDY的話，SPDY在減少移動(dòng)網(wǎng)站的延遲是非常有用的。

實(shí)現(xiàn)小貼士：依據(jù)網(wǎng)站和服務(wù)的環(huán)境來(lái)進(jìn)行平穩(wěn)操作或進(jìn)一步考慮。Google有一個(gè)SPDY模塊支持 Apache2.2 – mod_spdy – 這個(gè)模塊是免費(fèi)的；但是mod_spy有線程上的問(wèn)題，并且和mod_php協(xié)作并不是很好，所以要求你使用這個(gè)技術(shù)的時(shí)候要確保你的網(wǎng)站的正常運(yùn)行。 ^6

永遠(yuǎn)別忘記測(cè)試！

如果缺少了持續(xù)和仔細(xì)的測(cè)試提醒，性能的優(yōu)化就只是討論而已，是無(wú)法完成的。如果沒(méi)有指定基準(zhǔn)做比較，你系統(tǒng)上的任何改動(dòng)都僅僅是理論而已。如果沒(méi)有真實(shí)的測(cè)試數(shù)據(jù)，猜測(cè)性能的瓶頸是毫無(wú)意義的。

有很多開(kāi)源和通用的工具能進(jìn)行集成測(cè)試，并且能進(jìn)行不同地域和帶寬/延遲的測(cè)試。另外，RUM（real user monitoring）工具能將測(cè)試環(huán)境從實(shí)驗(yàn)室變成不可預(yù)測(cè)的真實(shí)用戶行為。

觀察移動(dòng)設(shè)備的測(cè)試選擇和桌面場(chǎng)景一樣。如果你在選擇一個(gè)自動(dòng)化的解決方案，請(qǐng)確保使用一個(gè)能持續(xù)測(cè)試，并且能區(qū)分出應(yīng)用優(yōu)化方法前后的變化的解決方案。

如果性能優(yōu)化如果只是在發(fā)展過(guò)程中的一個(gè)步驟而已，它不會(huì)有什么效果的。它必須成為一個(gè)持續(xù)改善網(wǎng)站的一部分。