對(duì)于加載精簡(jiǎn)來(lái)說(shuō)，最大的好處莫過(guò)于對(duì)頁(yè)面的加速。加速有兩點(diǎn)：

　　第一是由于資源加載量減少，對(duì)于頁(yè)面首屏加載速度的提升；

　　第二是某些加載精簡(jiǎn)的方法，會(huì)在一定程度上加快頁(yè)面的渲染速度。

同時(shí)，由于加載量的減少，剩下了一些帶寬，從而減少了帶寬費(fèi)用。

 

當(dāng)然，事情都有兩面的地方。加載精簡(jiǎn)會(huì)在一定程度上影響頁(yè)面的SEO；部分方法也會(huì)造成一些額外的腳本開(kāi)銷(xiāo)。

尋找合適你的方法很重要，畢竟每個(gè)網(wǎng)站性質(zhì)、用處、節(jié)點(diǎn)都可能不同。比如項(xiàng)目初期，可能宣傳和擴(kuò)散知名度方面重要些，這時(shí)候建議不要大量使用動(dòng)態(tài)生成內(nèi)容的方式，影響SEO。

 

第1章 存儲(chǔ)資源

1.1 離線存儲(chǔ)

1.1.1 為了移動(dòng)

由于瀏覽器支持情況不同，離線存儲(chǔ)在PC端沒(méi)有大量的使用，反而在移動(dòng)端的支持情況越來(lái)越好，如今Android、iOS都能使用離線存儲(chǔ)，所以離線存儲(chǔ)廣泛的使用于離線APP應(yīng)用。

對(duì)于離線存儲(chǔ)，最重要的便是manifest文件。我們將需要緩存的文件列入cache段，將不需要緩存的內(nèi)容列入network段即可。

圖2-1 manifest文件示例

當(dāng)瀏覽器加載頁(yè)面時(shí)，發(fā)現(xiàn)manifest文件后，會(huì)檢查它的內(nèi)容是不是有修改，如果是，重新下載cache段的文件并緩存；如果不是，則跳過(guò)。

圖2-2 更新離線緩存

需要注意的是，當(dāng)我們使用離線存儲(chǔ)時(shí)，瀏覽器會(huì)強(qiáng)行只讀離線緩存的文件。我們需要將頁(yè)面使用到的所有的資源都列入manifest文件中，不論是在cache段，還是network段。否則瀏覽器將報(bào)錯(cuò)，說(shuō)找不到文件。

圖2-3 未將所有文件列入的加載報(bào)錯(cuò)情況

1.1.2 更新

對(duì)離線存儲(chǔ)的資源更新，需要修改manifest文件的內(nèi)容。當(dāng)然，我們一般不會(huì)隨意修改文件名已達(dá)到修改manifest文件內(nèi)容的目的。一般的做法是，在文件內(nèi)新增一行注釋?zhuān)⑨屩袑?xiě)明目前的版本號(hào)，以后每次需要更新的時(shí)候，修改版本號(hào)就行了。

圖2-4 第二行即為注釋的版本信息

另外，我們可能需要功能更加強(qiáng)大的離線存儲(chǔ)緩存更新的機(jī)制。試想一個(gè)新聞?lì)惖腁PP，我們需要在手機(jī)離線時(shí)讀取本地存儲(chǔ)的數(shù)據(jù)，當(dāng)APP發(fā)現(xiàn)用戶(hù)聯(lián)網(wǎng)后，將讀取在線的內(nèi)容，更新本地的數(shù)據(jù)和頁(yè)面信息。

對(duì)于圖2-5，我們使用HTML5新提供的online時(shí)間在頁(yè)面加載的時(shí)候判斷手機(jī)是否在線。監(jiān)聽(tīng)window的online和offline時(shí)間，可以判斷手機(jī)是不是已經(jīng)聯(lián)網(wǎng)。一旦檢測(cè)到手機(jī)聯(lián)網(wǎng)，我們就可以調(diào)用applicationCache對(duì)象的update方法，去檢測(cè)manifest文件是否有更新，如果有，下載新的版本。當(dāng)updateready時(shí)，使用swapCache方法刷新緩存。

當(dāng)然swapCache不能刷新頁(yè)面的內(nèi)容，只是把離線存儲(chǔ)的文件更新成我們下載的新內(nèi)容，我們還需要再使用JS替換頁(yè)面的內(nèi)容。

圖2-5 離線存儲(chǔ)進(jìn)階應(yīng)用

1.1.3 殘缺美

在使用離線存儲(chǔ)的時(shí)候，總有些感到不是很爽的地方，列出來(lái)吐吐槽。

首先是兩個(gè)更新的問(wèn)題。我們知道，修改manifest文件后，瀏覽器會(huì)重新下載文件，而且是全部重新下載。這其實(shí)很蛋疼，有時(shí)候我們只需要更新其中一個(gè)文件，有點(diǎn)兒殃及池魚(yú)的感覺(jué)。另外，在更新manifest文件后，我們需要刷新兩次頁(yè)面才能將最終的新內(nèi)容呈現(xiàn)在頁(yè)面上。

然后，如果我有很多文件要存儲(chǔ)，需要把文件一個(gè)一個(gè)列入cache段里，就算使用程序生成，出來(lái)的manifest文件也有一定的體積。對(duì)于一個(gè)需要緩存300個(gè)文件的頁(yè)面，使用相對(duì)路徑，生成的manifest文件也有4K。在碰上更新的話(huà)，下載量有點(diǎn)兒大。

圖2-6 APP有200多個(gè)小圖標(biāo)需要緩存

最后，對(duì)于同一個(gè)頁(yè)面的帶參URL路徑，離線存儲(chǔ)會(huì)當(dāng)成不同的新文件進(jìn)行緩存。如果您有100個(gè)不同的參數(shù)需要穿，而用戶(hù)竟然訪問(wèn)過(guò)這100個(gè)文件，那就……

圖2-7 如果您有100個(gè)不同的傳參

1.2 本地存儲(chǔ)

1.2.1 本地存儲(chǔ)的方法

userData是IE提供的一個(gè)本地存儲(chǔ)方法，他將需要存儲(chǔ)的內(nèi)容放置在本地的一個(gè)XML文件中，并在頁(yè)面的一個(gè)元素中設(shè)置一個(gè)調(diào)用的錨點(diǎn)。具體使用方法為：使用getElementById獲取頁(yè)面內(nèi)的一個(gè)元素，使用addBehavior(“#default#userData”)對(duì)其添加本地存儲(chǔ)的行為；使用setAttribute將需要存儲(chǔ)的內(nèi)容對(duì)其進(jìn)行賦值，并用save(“XXX”)方法將內(nèi)容存儲(chǔ)在名為XXX的XML文件中；使用load(“XXX”)方法加載本地的XXX.xml文件，并用getAttribute獲取已經(jīng)存儲(chǔ)的內(nèi)容。

圖2-8 IE的本地存儲(chǔ)數(shù)據(jù)

關(guān)于HTML5本地存儲(chǔ)localStorage的詳細(xì)方法，請(qǐng)參見(jiàn)我的翻譯文章《網(wǎng)絡(luò)應(yīng)用程序本地存儲(chǔ)的前世今生》。

圖2-9 Chrome的本地存儲(chǔ)數(shù)據(jù)

對(duì)于IE瀏覽器，使用IE提供的userData方法；對(duì)于支持HTML5的瀏覽器(Firefox、Chrome、Safari、Opera等)，使用localStorage提供的方法；對(duì)于其他瀏覽器使用常規(guī)方法加載內(nèi)容。

圖2-10 判斷流程

1.2.2 資源處理

對(duì)于本地存儲(chǔ)，我們可以使用來(lái)存儲(chǔ)數(shù)據(jù)，或者能轉(zhuǎn)為數(shù)據(jù)形式的文件。例如一些SEO要求不高的文字，鏈接等等。

圖2-11 數(shù)據(jù)存儲(chǔ)

對(duì)于圖片、CSS、JS等文件，我們也可以轉(zhuǎn)為文本來(lái)存儲(chǔ)在本地。這種方式大量應(yīng)用于移動(dòng)端。例如《掌上英雄聯(lián)盟》APP的圖片大部分都轉(zhuǎn)化為base64編碼存儲(chǔ)在本地（不用離線存儲(chǔ)的原因前面提及了）。Google和Bing的移動(dòng)版，也將CSS和JS拆分后本地存儲(chǔ)了。

圖2-12 腳本的本地存儲(chǔ)

圖2-13 圖片轉(zhuǎn)base64編碼后的本地存儲(chǔ)

另外，對(duì)于本地存儲(chǔ)更新，我的做法是：先判斷本地是否存在已存儲(chǔ)的內(nèi)容，如果沒(méi)有數(shù)據(jù)或者版本已過(guò)期（所謂版本是我設(shè)置的一個(gè)變量，當(dāng)修改這個(gè)變量時(shí)即為版本過(guò)期），加載相應(yīng)的JS數(shù)據(jù)，通過(guò)一個(gè)函數(shù)將數(shù)據(jù)處理為需要的格式，然后存儲(chǔ)在本地；如果有且版本沒(méi)過(guò)期，直接從本地獲取數(shù)據(jù)。接著將數(shù)據(jù)通過(guò)函數(shù)進(jìn)行進(jìn)一步的處理，插入相對(duì)應(yīng)的結(jié)構(gòu)中。

圖2-14 本地?cái)?shù)據(jù)版本判斷

 

 

第2章 按需加載

2.1 滾動(dòng)加載

2.1.1 滾動(dòng)加載的方法

其實(shí)這是很多大型網(wǎng)站都使用了的方法，比如淘寶、拍拍等等。對(duì)于不同顯示器分辨率不同，所以第一屏高度不一樣，節(jié)省的加載量所浮動(dòng)。

首先，記錄所有需要滾動(dòng)加載對(duì)象的縱坐標(biāo)值到一個(gè)數(shù)組。然后使用JS的監(jiān)聽(tīng)方法（IE是attachEvent，其他瀏覽器是addEventListener），監(jiān)聽(tīng)頁(yè)面的scroll事件。一旦頁(yè)面滾動(dòng)，就會(huì)執(zhí)行一個(gè)編寫(xiě)的函數(shù)，來(lái)判斷對(duì)象是否處于瀏覽器的當(dāng)前一屏內(nèi)，如果是，將加載對(duì)象，如果不是，繼續(xù)監(jiān)聽(tīng)。當(dāng)頁(yè)面內(nèi)的所有對(duì)象都被加載后，取消監(jiān)聽(tīng)。

圖3-1 執(zhí)行流程

對(duì)于圖片，滾動(dòng)頁(yè)面后，我們可以看到如圖3-2的效果。

圖3-2 圖片滾動(dòng)加載過(guò)程

2.1.2 板塊滾動(dòng)加載

其實(shí)把每個(gè)板塊按照上面說(shuō)的那種方式，像圖片一樣，滾動(dòng)加載就可以實(shí)現(xiàn)這種效果，類(lèi)似于bigPipe+Lazyload。

我們將頁(yè)面拆分為框架、板塊、板塊內(nèi)容，甚至可以細(xì)分到板塊樣式、板塊腳本。當(dāng)頁(yè)面滾動(dòng)完成時(shí)，判斷處于當(dāng)前屏的板塊，動(dòng)態(tài)并行加載板塊內(nèi)容。這種方式可以大大減少頁(yè)面的加載量，但會(huì)影響SEO。

圖3-3 板塊滾動(dòng)加載方式

2.2 點(diǎn)擊加載

2.2.1 形式

點(diǎn)擊后動(dòng)態(tài)加載有很多形式，這是我們平時(shí)使用最多的方式。諸如頁(yè)卡、翻頁(yè)、展開(kāi)、下拉、切屏等等都會(huì)使用到。以往的我們可能直接在頁(yè)面寫(xiě)入內(nèi)容，或者使用include載入，并將看不到的內(nèi)容隱藏掉。但如果用戶(hù)并沒(méi)有點(diǎn)擊切換，那么直接加載這些內(nèi)容就產(chǎn)生多余的加載量。

圖3-4 觸發(fā)加載頁(yè)卡內(nèi)容

圖3-5 翻頁(yè)觸發(fā)動(dòng)態(tài)加載

2.2.2 觸發(fā)加載

一般來(lái)說(shuō)，動(dòng)態(tài)填充數(shù)據(jù)的前期判斷有兩種形式。

一種是使用條件語(yǔ)句，判斷內(nèi)容區(qū)域是否有內(nèi)容，如果沒(méi)有，填充內(nèi)容。這種方式最容易想到，但每次觸發(fā)的時(shí)候都會(huì)判斷一次。

另外一種是監(jiān)聽(tīng)的方式。我們監(jiān)聽(tīng)觸發(fā)的對(duì)象是否被點(diǎn)擊，如果點(diǎn)擊，就像目標(biāo)對(duì)象填充內(nèi)容，然后取消這個(gè)監(jiān)聽(tīng)。

圖3-6 判斷的兩種方式

很顯然，第二種方式只需執(zhí)行一次，測(cè)試結(jié)果也表明這種方式是最快的。

2.2.3 數(shù)據(jù)插入方式

我們的新聞系統(tǒng)在生成新聞列表的時(shí)候，會(huì)根據(jù)我們的模板同時(shí)生成html頁(yè)面、xml文件（我們很少使用）、json文件，在選擇將列表插入頁(yè)面的時(shí)候，我們有兩種方式。

一種是動(dòng)態(tài)加載json文件，用JS生成內(nèi)容，插入頁(yè)面；另一種是使用XHR加載html文件，使用responseText獲取內(nèi)容，插入頁(yè)面。

圖3-7 html文件

圖3-8 json文件

其實(shí)，使用第二種方法有明顯的好處。第一是，html文件體積比json文件小，加載量減少；第二是直接使用html文件，減少了JS動(dòng)態(tài)生成結(jié)構(gòu)的開(kāi)銷(xiāo)。

2.3 延時(shí)加載

對(duì)于一組有加載時(shí)間間隔的資源，我們其實(shí)可以對(duì)其做加載延時(shí)，按照其前后出現(xiàn)的順序，在時(shí)間間隔后即時(shí)加載下一個(gè)資源。例如輪播廣告就很適合這么做。

圖3-9 輪播廣告

2.3.1 輪播廣告

以往輪播廣告的加載模式是一次性全部加載，雖然采用延遲加載，但用戶(hù)可能不會(huì)瀏覽到所有的輪播廣告。當(dāng)用戶(hù)在首頁(yè)只停留5秒時(shí)（例如輪播廣告設(shè)置的是5秒切換一次），第二張廣告圖片以后的圖片加載就沒(méi)有必要了。

圖3-10 輪播廣告加載的請(qǐng)求瀑布圖

其實(shí)我們可以這樣，第一次加載第一張廣告圖片，當(dāng)5秒后，判斷第二張圖片是否加載過(guò)，如果沒(méi)有，加載第二張圖片，以此類(lèi)推。判斷的方式很簡(jiǎn)單，我們只要在初期生成輪播廣告結(jié)構(gòu)的時(shí)候，不設(shè)置img標(biāo)簽的src屬性，然后加載時(shí)判斷這張圖片是否有src屬性，如果沒(méi)有，加載圖片并設(shè)置這個(gè)屬性。

圖3-11 判斷方式

這樣，如果用戶(hù)在首頁(yè)停留時(shí)長(zhǎng)只有14秒，那么就節(jié)省了第4、5張廣告圖片的下載量，大約有100K左右。

圖3-12 優(yōu)化后的請(qǐng)求瀑布圖

 

第3章 其他方式

3.1 文件壓縮

3.1.1 代碼

老生常談的方法。我們可以將代碼里多余的空格，回車(chē)，無(wú)用標(biāo)簽刪除，替換名字較長(zhǎng)的變量名等等方式減少腳本文件大小。

圖4-1 腳本壓縮對(duì)比

3.1.2 多媒體

對(duì)于圖片，不同格式，不同壓縮率都會(huì)造成圖片大小的千差萬(wàn)別。選擇一個(gè)合適并且圖片質(zhì)量可以接受的壓縮方式，可以節(jié)省很大一筆加載量。

圖4-2 圖片壓縮對(duì)比

對(duì)于視頻、音頻、Flash來(lái)說(shuō)，也都一樣，碼率、格式等等方面都會(huì)對(duì)大小造成影響。

圖4-3 視頻壓縮對(duì)比

3.2 CSS 3

CSS 3是一個(gè)不算太新，但由于我朝瀏覽器限制而得不到大范圍應(yīng)用的技術(shù)。其實(shí)我們可以在一些效果表現(xiàn)不是很重要的頁(yè)面使用CSS 3來(lái)針對(duì)瀏覽器做一些差異化效果，已達(dá)到減少加載量的目的。

3.2.1 替換圖片

對(duì)于移動(dòng)端，或者一些PC頁(yè)面，我們可以用CSS 3來(lái)替換一些圖片效果，比如漸變、陰影、圓角等等。

圖4-4 綠色按鈕

例如圖4-4中的綠色按鈕，使用CSS 3漸變和圖片所造成的加載量差距很大，在能使用CSS 3的時(shí)候，盡量不要使用圖片。

圖4-5 CSS 3和圖片的大小對(duì)比

3.2.2 替換JS動(dòng)畫(huà)

一些對(duì)象移動(dòng)、寬高變換等效果，其實(shí)可以使用CSS 3動(dòng)畫(huà)來(lái)實(shí)現(xiàn)。例如使用CSS 3和JS，來(lái)實(shí)現(xiàn)一個(gè)對(duì)象左右切換的效果，需要的代碼量如圖4-6所示。我們可以看到，CSS 3的代碼量極少，而且執(zhí)行過(guò)程中沒(méi)有JS那些復(fù)雜的運(yùn)算。

圖4-6 CSS 3和JS的代碼量對(duì)比

3.3 服務(wù)器

3.3.1 GZIP

雅虎13條里的內(nèi)容。其壓縮比例很大，大部分網(wǎng)站都使用了。

圖4-7 gzip效果

3.3.2 緩存

設(shè)置Expires、Cache-Control以減少頁(yè)面加載量，使瀏覽器從本地讀取緩存。

Expires和Cache-Control max-age均用于檢測(cè)文件是否過(guò)期，如果沒(méi)有，瀏覽器讀取本地緩存。Expires是HTTP1.0的內(nèi)容，需要返回一個(gè)304 Not Modified，并且過(guò)期時(shí)間是GMT時(shí)間，一旦客戶(hù)端日期不準(zhǔn)確，可能導(dǎo)致失效。Cache-Control是HTTP1.1的內(nèi)容，使用文件自身的age值來(lái)做和請(qǐng)求時(shí)間對(duì)比，相對(duì)穩(wěn)定。

圖4-8 304 Not Modified

3.3.3 優(yōu)圖

優(yōu)圖是公司開(kāi)發(fā)的，用于圖片無(wú)損壓縮的系統(tǒng)。目前互娛已經(jīng)接入，在圖片上傳到服務(wù)器時(shí)，自動(dòng)進(jìn)行無(wú)損壓縮，加載量減少的效果非常明顯。

圖4-9 優(yōu)圖

 

第4章 三個(gè)話(huà)題

4.1 對(duì)比

在以前一次分享文檔中，有同學(xué)提問(wèn)為啥要拋開(kāi)瀏覽器與服務(wù)器的緩存機(jī)制，自己實(shí)現(xiàn)一套本地存儲(chǔ)機(jī)制，有沒(méi)有什么特別的優(yōu)勢(shì)。其實(shí)相對(duì)與傳統(tǒng)緩存來(lái)說(shuō)，本地存儲(chǔ)的好處有4點(diǎn)。

一是，對(duì)于存儲(chǔ)需要處理的數(shù)據(jù)來(lái)說(shuō)，本地存儲(chǔ)可以在第一次加載的時(shí)候就將處理的數(shù)據(jù)存在本地，而傳統(tǒng)緩存策略需要每次加載的時(shí)候都處理一次數(shù)據(jù)。

二是，本地存儲(chǔ)相對(duì)穩(wěn)定，有獨(dú)立的存儲(chǔ)空間，一般不會(huì)向服務(wù)器發(fā)送請(qǐng)求，而傳統(tǒng)緩存時(shí)常會(huì)丟失。

三是，相對(duì)于傳統(tǒng)緩存策略，本地存儲(chǔ)的讀取速度要更快些。當(dāng)然，也有例外，Chrome的本地存儲(chǔ)讀取速度要慢于緩存文件的加載。

四是，對(duì)于iOS設(shè)備，Safari在重啟后（包含本身的重啟，或者設(shè)備的重啟），緩存會(huì)被清空，而本地存儲(chǔ)和離線存儲(chǔ)不會(huì)。

4.2 SEO

4.2.1 Landing Page

對(duì)于互娛這邊的游戲，客戶(hù)端會(huì)有一個(gè)Landing Page，上面包含了最新的新聞，活動(dòng)等等信息，玩家每次啟動(dòng)客戶(hù)端都會(huì)看到這個(gè)頁(yè)面。

根據(jù)監(jiān)控，Landing Page平均每天給官網(wǎng)帶來(lái)250w左右的PV，而官網(wǎng)平均每日PV大約1000多萬(wàn)。這個(gè)量應(yīng)該完全填補(bǔ)了SEO的損失。而且游戲官網(wǎng)的用處一般僅限于給玩家提供游戲的功能服務(wù)、新聞、活動(dòng)信息等等，玩家查詢(xún)游戲攻略、資料一般會(huì)去媒體站，而不是游戲官網(wǎng)。

圖5-1 《英雄聯(lián)盟》的Landing Page

4.2.2 內(nèi)頁(yè)鏈接

在某些內(nèi)容需要?jiǎng)討B(tài)加載的時(shí)候，我們可以寫(xiě)一個(gè)到內(nèi)頁(yè)的鏈接，讓搜索引擎爬蟲(chóng)順著這個(gè)鏈接到內(nèi)頁(yè)去記錄信息。

圖5-2 到內(nèi)頁(yè)的鏈接

例如頁(yè)卡中的新聞列表需要?jiǎng)討B(tài)填充，如果不做處理，爬蟲(chóng)可能無(wú)法獲取這些列表中的新聞鏈接。我們可以像圖5-2的那兩種方式，寫(xiě)一個(gè)到列表頁(yè)的鏈接，這樣爬蟲(chóng)就可以順著這個(gè)鏈接到列表頁(yè)去抓取信息。

4.3 效果

4.3.1 健康度

健康度是我們以前接的加載時(shí)間檢測(cè)系統(tǒng)，最近我們換用了OZ系統(tǒng)。使用了以上方法的網(wǎng)站，在3秒健康度上，有了很大的提升。

圖5-3 3秒健康度

4.3.2 請(qǐng)求減少

采用以上方式減少加載量，雖然會(huì)造成整個(gè)網(wǎng)頁(yè)的全部請(qǐng)求量有少許增加，但因?yàn)槭前葱杓虞d，所以可以大大減少首屏請(qǐng)求量。

圖5-4 首屏請(qǐng)求量

圖5-5 整頁(yè)請(qǐng)求量

4.3.3 帶寬消耗

在我們接入優(yōu)圖后，圖片服務(wù)器的帶寬消耗大大減少。在圖片壓縮一半后，我們的帶寬消耗減少了4G。

圖5-6 圖片壓縮一半后服務(wù)器帶寬消耗趨勢(shì)圖

由于公司系統(tǒng)只能針對(duì)服務(wù)器做帶寬消耗監(jiān)控，所以我們看不到做文件存儲(chǔ)和按需加載后的帶寬減少情況，但我們可以大概算算。如果一個(gè)游戲官網(wǎng)全部頁(yè)面平均每天有PV1500w，用戶(hù)平均每次加載頁(yè)面節(jié)省10KB，假設(shè)第1天正常加載，后29天全部讀緩存，每月可以節(jié)省帶寬488MB。對(duì)于有幾十款游戲產(chǎn)品的我們來(lái)說(shuō)，這是一個(gè)很可觀的量。

 

結(jié)束語(yǔ)

正如開(kāi)篇所說(shuō)的那樣，介紹的這些方法，有部分會(huì)傷害SEO，增加腳本開(kāi)銷(xiāo)。所以大家在使用的時(shí)候需要進(jìn)行一個(gè)合理的選擇。

例如對(duì)于一個(gè)新產(chǎn)品，SEO相對(duì)更加重要些，這個(gè)時(shí)候可以適當(dāng)選用一些減少加載量的方法；當(dāng)產(chǎn)品成熟，有大量用戶(hù)的時(shí)候，可以考慮進(jìn)行更加深入的加載量?jī)?yōu)化。

希望此文檔能幫助到今后做網(wǎng)站加載量?jī)?yōu)化的同學(xué)。