摘要：要快，但是我們的服務也必須萬無一失，后續(xù)我會分享百度移動端首頁的前端架構設計那么這樣的優(yōu)化，是如何做到的呢，又如何兼顧穩(wěn)定性，架構性，與速度呢別急，讓我們把這些優(yōu)化一一道來。百度移動端首頁的很多就是這樣緩存在客戶端的。

歡迎大家收看聊一聊系列，這一套系列文章，可以幫助前端工程師們了解前端的方方面面（不僅僅是代碼）：https://segmentfault.com/blog/frontenddriver

這一期，咱們一起聊一聊----百度移動端首頁前端速度的那些事兒

我們的業(yè)務就是 https://m.baidu.com
別以為只有一個搜索框，我們還有下面豐富的卡片內容，可以提供各式各樣的服務。如圖1.1

圖1.1
其實整個頁面的邏輯相對是比較復雜的。
還有各式各樣的卡片，輕輕下拉，即可看到,如圖1.2

圖1.2

可能代碼的量級沒有很多webapp恐怖，可是“百度首頁要秒開”卻是一個共識，可以看到(如圖2.1)，在利用上了緩存的情況下，我們的首頁包大小gzip后只有11.1k左右。耗時也就是500多毫秒。大部分用戶“秒開”不是事兒。

圖2.1

但是，我們的業(yè)務在不斷的增長的同時，要維持這樣的包大小，就是一門藝術了。
要快，但是我們的服務也必須萬無一失，（后續(xù)我會分享百度移動端首頁的前端架構設計）那么這樣的優(yōu)化，是如何做到的呢，又如何兼顧穩(wěn)定性，架構性，與速度呢？別急，讓我們把這些優(yōu)化一一道來。

為了求快，首頁是沒有js和css外鏈的，這樣會再發(fā)起多次請求，相信對于各位前端小能手來說，也是老生常談的前端優(yōu)化了。所以，整個首頁渲染出來，只需要一次請求(除了iconfont)。其他的首屏所需要的js與css，全部在上線前，編譯時，編譯內聯(lián)至HTML中，如圖3.1.1。

圖3.1.1

然而，首頁并不滿足于此，首頁的很多樣式和腳本，需要在同步的時候就初始化，但是，如果每次都傳輸一些不變的靜態(tài)文件或者html，實在是太浪費了，如果html/css/js一直不變，那直接緩存到客戶端不就好了。
于是首頁的第二項優(yōu)化，就展示了威力，localstorage，關于這個客戶端存儲，陌生的同學可以查一查。也可以直接閱讀我接下來要寫的聊一聊系列文章。
我們把不變的js/css/html全部存儲到localstorage中去，下次加載首頁的時候。在特定的位置，不必再從服務端把特定位置的js/css/html傳過來。只需要傳一句話----""就行。
至于存儲的方法，例子如下：

    
        
    
    
        

            這部分內容非常多將會緩存起來
            這部分內容非常多將會緩存起來
            這部分內容非常多將會緩存起來
            這部分內容非常多將會緩存起來
            這部分內容非常多將會緩存起來
            這部分內容非常多將會緩存起來
            這部分內容非常多將會緩存起來
            這部分內容非常多將會緩存起來
            這部分內容非常多將會緩存起來
            這部分內容非常多將會緩存起來
            這部分內容非常多將會緩存起來
            這部分內容非常多將會緩存起來
            這部分內容非常多將會緩存起來
            這部分內容非常多將會緩存起來
            這部分內容非常多將會緩存起來
            這部分內容非常多將會緩存起來
            這部分內容非常多將會緩存起來
            這部分內容非常多將會緩存起來
            這部分內容非常多將會緩存起來
            這部分內容非常多將會緩存起來
            這部分內容非常多將會緩存起來
        
        
    

我們將html的內容存儲到了localstorage中，如圖3.2.1

圖3.2.1
下次，再訪問的時候，我們使用服務端把緩存起來的html不傳送，而是只傳送讀取相關的js，如圖3.2.2

圖3.2.2
我們看到，雖然展示內容相同，但是第二次傳輸?shù)臅r候，頁面的量明顯減小。而且使用這種方式我們使用的地方越多，這種優(yōu)勢就越明顯。

百度移動端首頁的很多css/html/js就是這樣緩存在客戶端的。

有同學會說，那么如何知道什么時候該傳讀local，什么時候該傳寫local呢？
很簡單，我們在寫入local的時候，同時在cookie中種下當前所有要緩存的內容的版本(MD5戳)就行。
因為cookie是會在同步訪問的時候，傳送到服務端的，而local不會，所以，我們在服務端決定要傳送內容，還是傳送讀取local代碼。就靠我們種下的cookie了。我們在這里，使用php來做一個實驗：

    
        
    
    
        
         
        

            這部分內容非常多將會緩存起來
            這部分內容非常多將會緩存起來
            這部分內容非常多將會緩存起來
            這部分內容非常多將會緩存起來
            這部分內容非常多將會緩存起來
            這部分內容非常多將會緩存起來
            這部分內容非常多將會緩存起來
            這部分內容非常多將會緩存起來
            這部分內容非常多將會緩存起來
            這部分內容非常多將會緩存起來
            這部分內容非常多將會緩存起來
            這部分內容非常多將會緩存起來
            這部分內容非常多將會緩存起來
            這部分內容非常多將會緩存起來
            這部分內容非常多將會緩存起來
            這部分內容非常多將會緩存起來
            這部分內容非常多將會緩存起來
            這部分內容非常多將會緩存起來
            這部分內容非常多將會緩存起來
            這部分內容非常多將會緩存起來
            這部分內容非常多將會緩存起來
        
        
        
            
        
    

我們在php中判斷，如果cookie中有version，證明種過cookie，寫過local，所以，不用傳內容了，直接傳script就好了，如果沒有就要傳輸并且寫入。我們可以看到效果，同樣的頁面，第一次訪問的時候，內容大小是1.6K，如圖3.2.3

圖3.2.3
再次刷新的時候，內容量已經(jīng)減小到了474b，如圖3.2.4。

圖3.2.4

如果用戶的cookie和local不一致怎么辦，如果用戶不支持local怎么辦？這些疑問其他讀者自行思考一下(其實很簡單)。

畢竟業(yè)務龐大，光首屏的那些css/js/html已經(jīng)無法滿足我們了。我們需要更多的腳本，更多的css。你可能會很輕松的想到，外鏈引入唄。但是，經(jīng)過調研，我們發(fā)現(xiàn)移動端的文件緩存率非常的低(大約30%左右)。也就是說移動端的緩存環(huán)境是非常殘酷的。所以，我們又開始了極限優(yōu)化。我們將所有的js/css等靜態(tài)文件，通過一個接口全部返回。如圖3.3.1

圖3.3.1
這樣可以達到合并外鏈請求的目的，我們又將這些靜態(tài)文件，也一一緩存到localstorage中，如圖3.3.2：

圖3.3.2
每個文件以自己文件內容生成的版本號為戳，標識自己的唯一性。每次服務端返回頁面時，會把當前在服務器上的所有靜態(tài)文件版本號，返給前端，如圖3.3.3

圖3.3.3
前端首屏加載完成后，會用這些版本號與local中進行一一對比，發(fā)現(xiàn)不一致的js/css，會一起發(fā)送一個合并請求。如圖3.3.1所示。這樣可以保證每個文件的緩存與版本迭代。同時，也避免了過多的外鏈。

我們的模板和數(shù)據(jù)，也會被緩存至localstorage中，，有同學可能會問，那什么東西不緩存？答案就是，變化的東西，如果有部分html與數(shù)據(jù)在刷新的時候會經(jīng)常性的變動的話，這種緩存方式就失去了它的意義，我們的宗旨是，不變的數(shù)據(jù)，緩存下來是可以帶來信息量的不重復傳輸?shù)?/strong>。如圖3.4.1

不要走開，請關注我。下一章，我們將繼續(xù)聊聊web分辨率那些事兒。