對于加載精簡來說，最大的好處莫過于對頁面的加速。加速有兩點(diǎn)：

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

　　第二是某些加載精簡的方法，會在一定程度上加快頁面的渲染速度。

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

 

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

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

 

第1章 存儲資源

1.1 離線存儲

1.1.1 為了移動

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

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

圖2-1 manifest文件示例

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

圖2-2 更新離線緩存

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

圖2-3 未將所有文件列入的加載報錯情況

1.1.2 更新

對離線存儲的資源更新，需要修改manifest文件的內(nèi)容。當(dāng)然，我們一般不會隨意修改文件名已達(dá)到修改manifest文件內(nèi)容的目的。一般的做法是，在文件內(nèi)新增一行注釋，注釋中寫明目前的版本號，以后每次需要更新的時候，修改版本號就行了。

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

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

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

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

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

1.1.3 殘缺美

在使用離線存儲的時候，總有些感到不是很爽的地方，列出來吐吐槽。

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

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

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

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

圖2-7 如果您有100個不同的傳參

1.2 本地存儲

1.2.1 本地存儲的方法

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

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

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

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

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

圖2-10 判斷流程

1.2.2 資源處理

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

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

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

圖2-12 腳本的本地存儲

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

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

圖2-14 本地數(shù)據(jù)版本判斷

 

 

第2章 按需加載

2.1 滾動加載

2.1.1 滾動加載的方法

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

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

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

對于圖片，滾動頁面后，我們可以看到如圖3-2的效果。

圖3-2 圖片滾動加載過程

2.1.2 板塊滾動加載

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

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

圖3-3 板塊滾動加載方式

2.2 點(diǎn)擊加載

2.2.1 形式

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

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

圖3-5 翻頁觸發(fā)動態(tài)加載

2.2.2 觸發(fā)加載

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

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

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

圖3-6 判斷的兩種方式

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

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

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

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

圖3-7 html文件

圖3-8 json文件

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

2.3 延時加載

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

圖3-9 輪播廣告

2.3.1 輪播廣告

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

圖3-10 輪播廣告加載的請求瀑布圖

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

圖3-11 判斷方式

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

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

 

第3章 其他方式

3.1 文件壓縮

3.1.1 代碼

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

圖4-1 腳本壓縮對比

3.1.2 多媒體

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

圖4-2 圖片壓縮對比

對于視頻、音頻、Flash來說，也都一樣，碼率、格式等等方面都會對大小造成影響。

圖4-3 視頻壓縮對比

3.2 CSS 3

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

3.2.1 替換圖片

對于移動端，或者一些PC頁面，我們可以用CSS 3來替換一些圖片效果，比如漸變、陰影、圓角等等。

圖4-4 綠色按鈕

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

圖4-5 CSS 3和圖片的大小對比

3.2.2 替換JS動畫

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

圖4-6 CSS 3和JS的代碼量對比

3.3 服務(wù)器

3.3.1 GZIP

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

圖4-7 gzip效果

3.3.2 緩存

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

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

圖4-8 304 Not Modified

3.3.3 優(yōu)圖

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

圖4-9 優(yōu)圖

 

第4章 三個話題

4.1 對比

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

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

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

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

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

4.2 SEO

4.2.1 Landing Page

對于互娛這邊的游戲，客戶端會有一個Landing Page，上面包含了最新的新聞，活動等等信息，玩家每次啟動客戶端都會看到這個頁面。

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

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

4.2.2 內(nèi)頁鏈接

在某些內(nèi)容需要動態(tài)加載的時候，我們可以寫一個到內(nèi)頁的鏈接，讓搜索引擎爬蟲順著這個鏈接到內(nèi)頁去記錄信息。

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

例如頁卡中的新聞列表需要動態(tài)填充，如果不做處理，爬蟲可能無法獲取這些列表中的新聞鏈接。我們可以像圖5-2的那兩種方式，寫一個到列表頁的鏈接，這樣爬蟲就可以順著這個鏈接到列表頁去抓取信息。

4.3 效果

4.3.1 健康度

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

圖5-3 3秒健康度

4.3.2 請求減少

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

圖5-4 首屏請求量

圖5-5 整頁請求量

4.3.3 帶寬消耗

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

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

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

 

結(jié)束語

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

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

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