對于加載精簡來說,最大的好處莫過于對頁面的加速。加速有兩點:
第一是由于資源加載量減少,對于頁面首屏加載速度的提升;
第二是某些加載精簡的方法,會在一定程度上加快頁面的渲染速度。
同時,由于加載量的減少,剩下了一些帶寬,從而減少了帶寬費用。
當然,事情都有兩面的地方。加載精簡會在一定程度上影響頁面的SEO;部分方法也會造成一些額外的腳本開銷。
尋找合適你的方法很重要,畢竟每個網(wǎng)站性質(zhì)、用處、節(jié)點都可能不同。比如項目初期,可能宣傳和擴散知名度方面重要些,這時候建議不要大量使用動態(tài)生成內(nèi)容的方式,影響SEO。
第1章 存儲資源
1.1 離線存儲
1.1.1 為了移動
由于瀏覽器支持情況不同,離線存儲在PC端沒有大量的使用,反而在移動端的支持情況越來越好,如今Android、iOS都能使用離線存儲,所以離線存儲廣泛的使用于離線APP應用。
對于離線存儲,最重要的便是manifest文件。我們將需要緩存的文件列入cache段,將不需要緩存的內(nèi)容列入network段即可。
圖2-1 manifest文件示例
當瀏覽器加載頁面時,發(fā)現(xiàn)manifest文件后,會檢查它的內(nèi)容是不是有修改,如果是,重新下載cache段的文件并緩存;如果不是,則跳過。
圖2-2 更新離線緩存
需要注意的是,當我們使用離線存儲時,瀏覽器會強行只讀離線緩存的文件。我們需要將頁面使用到的所有的資源都列入manifest文件中,不論是在cache段,還是network段。否則瀏覽器將報錯,說找不到文件。
圖2-3 未將所有文件列入的加載報錯情況
1.1.2 更新
對離線存儲的資源更新,需要修改manifest文件的內(nèi)容。當然,我們一般不會隨意修改文件名已達到修改manifest文件內(nèi)容的目的。一般的做法是,在文件內(nèi)新增一行注釋,注釋中寫明目前的版本號,以后每次需要更新的時候,修改版本號就行了。
圖2-4 第二行即為注釋的版本信息
另外,我們可能需要功能更加強大的離線存儲緩存更新的機制。試想一個新聞類的APP,我們需要在手機離線時讀取本地存儲的數(shù)據(jù),當APP發(fā)現(xiàn)用戶聯(lián)網(wǎng)后,將讀取在線的內(nèi)容,更新本地的數(shù)據(jù)和頁面信息。
對于圖2-5,我們使用HTML5新提供的online時間在頁面加載的時候判斷手機是否在線。監(jiān)聽window的online和offline時間,可以判斷手機是不是已經(jīng)聯(lián)網(wǎng)。一旦檢測到手機聯(lián)網(wǎng),我們就可以調(diào)用applicationCache對象的update方法,去檢測manifest文件是否有更新,如果有,下載新的版本。當updateready時,使用swapCache方法刷新緩存。
當然swapCache不能刷新頁面的內(nèi)容,只是把離線存儲的文件更新成我們下載的新內(nèi)容,我們還需要再使用JS替換頁面的內(nèi)容。
圖2-5 離線存儲進階應用
1.1.3 殘缺美
在使用離線存儲的時候,總有些感到不是很爽的地方,列出來吐吐槽。
首先是兩個更新的問題。我們知道,修改manifest文件后,瀏覽器會重新下載文件,而且是全部重新下載。這其實很蛋疼,有時候我們只需要更新其中一個文件,有點兒殃及池魚的感覺。另外,在更新manifest文件后,我們需要刷新兩次頁面才能將最終的新內(nèi)容呈現(xiàn)在頁面上。
然后,如果我有很多文件要存儲,需要把文件一個一個列入cache段里,就算使用程序生成,出來的manifest文件也有一定的體積。對于一個需要緩存300個文件的頁面,使用相對路徑,生成的manifest文件也有4K。在碰上更新的話,下載量有點兒大。
圖2-6 APP有200多個小圖標需要緩存
最后,對于同一個頁面的帶參URL路徑,離線存儲會當成不同的新文件進行緩存。如果您有100個不同的參數(shù)需要穿,而用戶竟然訪問過這100個文件,那就……
圖2-7 如果您有100個不同的傳參
1.2 本地存儲
1.2.1 本地存儲的方法
userData是IE提供的一個本地存儲方法,他將需要存儲的內(nèi)容放置在本地的一個XML文件中,并在頁面的一個元素中設置一個調(diào)用的錨點。具體使用方法為:使用getElementById獲取頁面內(nèi)的一個元素,使用addBehavior(“#default#userData”)對其添加本地存儲的行為;使用setAttribute將需要存儲的內(nèi)容對其進行賦值,并用save(“XXX”)方法將內(nèi)容存儲在名為XXX的XML文件中;使用load(“XXX”)方法加載本地的XXX.xml文件,并用getAttribute獲取已經(jīng)存儲的內(nèi)容。
圖2-8 IE的本地存儲數(shù)據(jù)
關于HTML5本地存儲localStorage的詳細方法,請參見我的翻譯文章《網(wǎ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)為文本來存儲在本地。這種方式大量應用于移動端。例如《掌上英雄聯(lián)盟》APP的圖片大部分都轉(zhuǎn)化為base64編碼存儲在本地(不用離線存儲的原因前面提及了)。Google和Bing的移動版,也將CSS和JS拆分后本地存儲了。
圖2-12 腳本的本地存儲
圖2-13 圖片轉(zhuǎn)base64編碼后的本地存儲
另外,對于本地存儲更新,我的做法是:先判斷本地是否存在已存儲的內(nèi)容,如果沒有數(shù)據(jù)或者版本已過期(所謂版本是我設置的一個變量,當修改這個變量時即為版本過期),加載相應的JS數(shù)據(jù),通過一個函數(shù)將數(shù)據(jù)處理為需要的格式,然后存儲在本地;如果有且版本沒過期,直接從本地獲取數(shù)據(jù)。接著將數(shù)據(jù)通過函數(shù)進行進一步的處理,插入相對應的結(jié)構(gòu)中。
圖2-14 本地數(shù)據(jù)版本判斷
第2章 按需加載
2.1 滾動加載
2.1.1 滾動加載的方法
其實這是很多大型網(wǎng)站都使用了的方法,比如淘寶、拍拍等等。對于不同顯示器分辨率不同,所以第一屏高度不一樣,節(jié)省的加載量所浮動。
首先,記錄所有需要滾動加載對象的縱坐標值到一個數(shù)組。然后使用JS的監(jiān)聽方法(IE是attachEvent,其他瀏覽器是addEventListener),監(jiān)聽頁面的scroll事件。一旦頁面滾動,就會執(zhí)行一個編寫的函數(shù),來判斷對象是否處于瀏覽器的當前一屏內(nèi),如果是,將加載對象,如果不是,繼續(xù)監(jiān)聽。當頁面內(nèi)的所有對象都被加載后,取消監(jiān)聽。
圖3-1 執(zhí)行流程
對于圖片,滾動頁面后,我們可以看到如圖3-2的效果。
圖3-2 圖片滾動加載過程
2.1.2 板塊滾動加載
其實把每個板塊按照上面說的那種方式,像圖片一樣,滾動加載就可以實現(xiàn)這種效果,類似于bigPipe+Lazyload。
我們將頁面拆分為框架、板塊、板塊內(nèi)容,甚至可以細分到板塊樣式、板塊腳本。當頁面滾動完成時,判斷處于當前屏的板塊,動態(tài)并行加載板塊內(nèi)容。這種方式可以大大減少頁面的加載量,但會影響SEO。
圖3-3 板塊滾動加載方式
2.2 點擊加載
2.2.1 形式
點擊后動態(tài)加載有很多形式,這是我們平時使用最多的方式。諸如頁卡、翻頁、展開、下拉、切屏等等都會使用到。以往的我們可能直接在頁面寫入內(nèi)容,或者使用include載入,并將看不到的內(nèi)容隱藏掉。但如果用戶并沒有點擊切換,那么直接加載這些內(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ā)的對象是否被點擊,如果點擊,就像目標對象填充內(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文件
其實,使用第二種方法有明顯的好處。第一是,html文件體積比json文件小,加載量減少;第二是直接使用html文件,減少了JS動態(tài)生成結(jié)構(gòu)的開銷。
2.3 延時加載
對于一組有加載時間間隔的資源,我們其實可以對其做加載延時,按照其前后出現(xiàn)的順序,在時間間隔后即時加載下一個資源。例如輪播廣告就很適合這么做。
圖3-9 輪播廣告
2.3.1 輪播廣告
以往輪播廣告的加載模式是一次性全部加載,雖然采用延遲加載,但用戶可能不會瀏覽到所有的輪播廣告。當用戶在首頁只停留5秒時(例如輪播廣告設置的是5秒切換一次),第二張廣告圖片以后的圖片加載就沒有必要了。
圖3-10 輪播廣告加載的請求瀑布圖
其實我們可以這樣,第一次加載第一張廣告圖片,當5秒后,判斷第二張圖片是否加載過,如果沒有,加載第二張圖片,以此類推。判斷的方式很簡單,我們只要在初期生成輪播廣告結(jié)構(gòu)的時候,不設置img標簽的src屬性,然后加載時判斷這張圖片是否有src屬性,如果沒有,加載圖片并設置這個屬性。
圖3-11 判斷方式
這樣,如果用戶在首頁停留時長只有14秒,那么就節(jié)省了第4、5張廣告圖片的下載量,大約有100K左右。
圖3-12 優(yōu)化后的請求瀑布圖
第3章 其他方式
3.1 文件壓縮
3.1.1 代碼
老生常談的方法。我們可以將代碼里多余的空格,回車,無用標簽刪除,替換名字較長的變量名等等方式減少腳本文件大小。
圖4-1 腳本壓縮對比
3.1.2 多媒體
對于圖片,不同格式,不同壓縮率都會造成圖片大小的千差萬別。選擇一個合適并且圖片質(zhì)量可以接受的壓縮方式,可以節(jié)省很大一筆加載量。
圖4-2 圖片壓縮對比
對于視頻、音頻、Flash來說,也都一樣,碼率、格式等等方面都會對大小造成影響。
圖4-3 視頻壓縮對比
3.2 CSS 3
CSS 3是一個不算太新,但由于我朝瀏覽器限制而得不到大范圍應用的技術(shù)。其實我們可以在一些效果表現(xiàn)不是很重要的頁面使用CSS 3來針對瀏覽器做一些差異化效果,已達到減少加載量的目的。
3.2.1 替換圖片
對于移動端,或者一些PC頁面,我們可以用CSS 3來替換一些圖片效果,比如漸變、陰影、圓角等等。
圖4-4 綠色按鈕
例如圖4-4中的綠色按鈕,使用CSS 3漸變和圖片所造成的加載量差距很大,在能使用CSS 3的時候,盡量不要使用圖片。
圖4-5 CSS 3和圖片的大小對比
3.2.2 替換JS動畫
一些對象移動、寬高變換等效果,其實可以使用CSS 3動畫來實現(xiàn)。例如使用CSS 3和JS,來實現(xiàn)一個對象左右切換的效果,需要的代碼量如圖4-6所示。我們可以看到,CSS 3的代碼量極少,而且執(zhí)行過程中沒有JS那些復雜的運算。
圖4-6 CSS 3和JS的代碼量對比
3.3 服務器
3.3.1 GZIP
雅虎13條里的內(nèi)容。其壓縮比例很大,大部分網(wǎng)站都使用了。
圖4-7 gzip效果
3.3.2 緩存
設置Expires、Cache-Control以減少頁面加載量,使瀏覽器從本地讀取緩存。
Expires和Cache-Control
max-age均用于檢測文件是否過期,如果沒有,瀏覽器讀取本地緩存。Expires是HTTP1.0的內(nèi)容,需要返回一個304 Not Modified,并且過期時間是GMT時間,一旦客戶端日期不準確,可能導致失效。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)接入,在圖片上傳到服務器時,自動進行無損壓縮,加載量減少的效果非常明顯。
圖4-9 優(yōu)圖
第4章 三個話題
4.1 對比
在以前一次分享文檔中,有同學提問為啥要拋開瀏覽器與服務器的緩存機制,自己實現(xiàn)一套本地存儲機制,有沒有什么特別的優(yōu)勢。其實相對與傳統(tǒng)緩存來說,本地存儲的好處有4點。
一是,對于存儲需要處理的數(shù)據(jù)來說,本地存儲可以在第一次加載的時候就將處理的數(shù)據(jù)存在本地,而傳統(tǒng)緩存策略需要每次加載的時候都處理一次數(shù)據(jù)。
二是,本地存儲相對穩(wěn)定,有獨立的存儲空間,一般不會向服務器發(fā)送請求,而傳統(tǒng)緩存時常會丟失。
三是,相對于傳統(tǒng)緩存策略,本地存儲的讀取速度要更快些。當然,也有例外,Chrome的本地存儲讀取速度要慢于緩存文件的加載。
四是,對于iOS設備,Safari在重啟后(包含本身的重啟,或者設備的重啟),緩存會被清空,而本地存儲和離線存儲不會。
4.2 SEO
4.2.1 Landing Page
對于互娛這邊的游戲,客戶端會有一個Landing Page,上面包含了最新的新聞,活動等等信息,玩家每次啟動客戶端都會看到這個頁面。
根據(jù)監(jiān)控,Landing Page平均每天給官網(wǎng)帶來250w左右的PV,而官網(wǎng)平均每日PV大約1000多萬。這個量應該完全填補了SEO的損失。而且游戲官網(wǎng)的用處一般僅限于給玩家提供游戲的功能服務、新聞、活動信息等等,玩家查詢游戲攻略、資料一般會去媒體站,而不是游戲官網(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)頁的全部請求量有少許增加,但因為是按需加載,所以可以大大減少首屏請求量。
圖5-4 首屏請求量
圖5-5 整頁請求量
4.3.3 帶寬消耗
在我們接入優(yōu)圖后,圖片服務器的帶寬消耗大大減少。在圖片壓縮一半后,我們的帶寬消耗減少了4G。
圖5-6 圖片壓縮一半后服務器帶寬消耗趨勢圖
由于公司系統(tǒng)只能針對服務器做帶寬消耗監(jiān)控,所以我們看不到做文件存儲和按需加載后的帶寬減少情況,但我們可以大概算算。如果一個游戲官網(wǎng)全部頁面平均每天有PV1500w,用戶平均每次加載頁面節(jié)省10KB,假設第1天正常加載,后29天全部讀緩存,每月可以節(jié)省帶寬488MB。對于有幾十款游戲產(chǎn)品的我們來說,這是一個很可觀的量。
結(jié)束語
正如開篇所說的那樣,介紹的這些方法,有部分會傷害SEO,增加腳本開銷。所以大家在使用的時候需要進行一個合理的選擇。
例如對于一個新產(chǎn)品,SEO相對更加重要些,這個時候可以適當選用一些減少加載量的方法;當產(chǎn)品成熟,有大量用戶的時候,可以考慮進行更加深入的加載量優(yōu)化。
希望此文檔能幫助到今后做網(wǎng)站加載量優(yōu)化的同學。
評論(0人參與,0條評論)
發(fā)布評論
最新評論