網(wǎng)站加載量?jī)?yōu)化:網(wǎng)頁加載性能優(yōu)化詳解

申請(qǐng)免費(fèi)試用、咨詢電話：400-8352-114

對(duì)于加載精簡(jiǎn)來說，最大的好處莫過于對(duì)頁面的加速。加速有兩點(diǎn)：第一是由于資源加載量減少，對(duì)于頁面首屏加載速度的提升；第二是某些加載精簡(jiǎn)的方法，會(huì)在一定程度上加快頁面的渲染速度。同時(shí)，由于加載量的減少，剩下了一些帶寬，從而減少了帶寬費(fèi)用。

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

尋找合適你的方法很重要，畢竟每個(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端沒有大量的使用，反而在移動(dòng)端的支持情況越來越好，如今Android、iOS都能使用離線存儲(chǔ)，所以離線存儲(chǔ)廣泛的使用于離線APP應(yīng)用。

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

圖2-1 manifest文件示例

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

圖2-2 更新離線緩存

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

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

1.1.2 更新

對(duì)離線存儲(chǔ)的資源更新，需要修改manifest文件的內(nèi)容。當(dāng)然，我們一般不會(huì)隨意修改文件名已達(dá)到修改manifest文件內(nèi)容的目的。一般的做法是，在文件內(nèi)新增一行注釋，注釋中寫明目前的版本號(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)用戶聯(lián)網(wǎng)后，將讀取在線的內(nèi)容，更新本地的數(shù)據(jù)和頁面信息。

對(duì)于圖2-5，我們使用HTML5新提供的online時(shí)間在頁面加載的時(shí)候判斷手機(jī)是否在線。監(jiān)聽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不能刷新頁面的內(nèi)容，只是把離線存儲(chǔ)的文件更新成我們下載的新內(nèi)容，我們還需要再使用JS替換頁面的內(nèi)容。

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

1.1.3 殘缺美

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

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

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

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

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

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

1.2 本地存儲(chǔ)

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

userData是IE提供的一個(gè)本地存儲(chǔ)方法，他將需要存儲(chǔ)的內(nèi)容放置在本地的一個(gè)XML文件中，并在頁面的一個(gè)元素中設(shè)置一個(gè)調(diào)用的錨點(diǎn)。具體使用方法為：使用getElementById獲取頁面內(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)參見我的翻譯文章《網(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ǔ)，我們可以使用來存儲(chǔ)數(shù)據(jù)，或者能轉(zhuǎn)為數(shù)據(jù)形式的文件。例如一些SEO要求不高的文字，鏈接等等。

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

對(duì)于圖片、CSS、JS等文件，我們也可以轉(zhuǎn)為文本來存儲(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)容，如果沒有數(shù)據(jù)或者版本已過期（所謂版本是我設(shè)置的一個(gè)變量，當(dāng)修改這個(gè)變量時(shí)即為版本過期），加載相應(yīng)的JS數(shù)據(jù)，通過一個(gè)函數(shù)將數(shù)據(jù)處理為需要的格式，然后存儲(chǔ)在本地；如果有且版本沒過期，直接從本地獲取數(shù)據(jù)。接著將數(shù)據(jù)通過函數(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)聽方法（IE是attachEvent，其他瀏覽器是addEventListener），監(jiān)聽頁面的scroll事件。一旦頁面滾動(dòng)，就會(huì)執(zhí)行一個(gè)編寫的函數(shù)，來判斷對(duì)象是否處于瀏覽器的當(dāng)前一屏內(nèi)，如果是，將加載對(duì)象，如果不是，繼續(xù)監(jiān)聽。當(dāng)頁面內(nèi)的所有對(duì)象都被加載后，取消監(jiān)聽。

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

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

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

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

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

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

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

2.2 點(diǎn)擊加載

2.2.1 形式

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

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

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

2.2.2 觸發(fā)加載

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

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

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

圖3-6 判斷的兩種方式

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

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

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

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

圖3-7 html文件

圖3-8 json文件

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

2.3 延時(shí)加載

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

圖3-9 輪播廣告

2.3.1 輪播廣告

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

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

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

圖3-11 判斷方式

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

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

第3章 其他方式

3.1 文件壓縮

3.1.1 代碼

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

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

3.1.2 多媒體

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

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

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

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

3.2 CSS 3

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

3.2.1 替換圖片

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

圖4-4 綠色按鈕

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

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

3.2.2 替換JS動(dòng)畫

一些對(duì)象移動(dòng)、寬高變換等效果，其實(shí)可以使用CSS 3動(dòng)畫來實(shí)現(xiàn)。例如使用CSS 3和JS，來實(shí)現(xiàn)一個(gè)對(duì)象左右切換的效果，需要的代碼量如圖4-6所示。我們可以看到，CSS 3的代碼量極少，而且執(zhí)行過程中沒有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以減少頁面加載量，使瀏覽器從本地讀取緩存。

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

圖4-8 304 Not Modified

3.3.3 優(yōu)圖

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

圖4-9 優(yōu)圖

第4章 三個(gè)話題

4.1 對(duì)比

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

一是，對(duì)于存儲(chǔ)需要處理的數(shù)據(jù)來說，本地存儲(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ì)于互娛這邊的游戲，客戶端會(huì)有一個(gè)Landing Page，上面包含了最新的新聞，活動(dòng)等等信息，玩家每次啟動(dòng)客戶端都會(huì)看到這個(gè)頁面。

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

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

4.2.2 內(nèi)頁鏈接

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

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

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

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)頁的全部請(qǐng)求量有少許增加，但因?yàn)槭前葱杓虞d，所以可以大大減少首屏請(qǐng)求量。

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

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

4.3.3 帶寬消耗

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

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

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

結(jié)束語

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

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

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