前端優化：瀏覽器緩存技術介紹

0 前言

在前端開發中，性能一直都是被你們所重視的一點，然而判斷一個網站的性能最直觀的就是看網頁打開的速度。其中提升網頁反應速度的一個方式就是使用緩存。緩存技術一直一來在WEB技術體系中扮演很是重要角色，是快速且有效地提高性能的手段。

一個優秀的緩存策略能夠縮短網頁請求資源的距離，減小延遲，而且因爲緩存文件能夠重複利用，還能夠減小帶寬，下降網絡負荷。

因此，緩存技術是無數WEB開發從業人員在工做過程當中不可避免的一大問題。在產品開發的時候咱們老是想辦法避免緩存產生，而在產品發佈之時又在想策略管理緩存提高網頁的訪問速度。瞭解瀏覽器的緩存命中原理，是開發WEB應用的基礎，本文着眼於此，學習瀏覽器緩存的相關知識，總結緩存避免和緩存管理的方法，結合具體的場景說明緩存的相關問題。但願能對有須要的人有所幫助。

1 WEB緩存體系

在實際WEB開發過程當中，緩存技術會涉及到不一樣層、不一樣端，好比：用戶層、系統層、代理層、前端、後端、服務端等，每一層的緩存目標都是一致的，就是儘快返回請求數據、減小延遲，但每層使用的技術實現是各有不一樣，面對不一樣層、不一樣端的優劣，選用不一樣的技術來提高系統響應效率。因此，咱們首先看下各層的緩存都有哪些技術，都緩存哪些數據，從總體上，對WEB的緩存技術進行了解，以下圖所示：

本篇文章重點講的就是上面紅色框部分緩存內容。

2 認識瀏覽器緩存

當瀏覽器請求一個網站的時候，會加載各類各樣的資源，好比：HTML文檔、圖片、CSS和JS等文件。對於一些不常常變的內容，瀏覽器會將他們保存在本地的文件中，下次訪問相同網站的時候，直接加載這些資源，加速訪問。

這些被瀏覽器保存的文件就被稱爲緩存（不是指Cookie或者Localstorage）。

那麼如何知曉瀏覽器是讀取了緩存仍是直接請求服務器？以下圖網站來作個示例：

第一次打開該網站後，若是再次刷新頁面。會發現瀏覽器加載的衆多資源中，有一部分size有具體數值，然而還有一部分請求，好比圖片、css和js等文件並無顯示文件大小，而是顯示了 from dis cache 或者 from memory cache 字樣。這就說明了，該資源直接從本地硬盤或者瀏覽器內存讀取，而並無請求服務器。

瀏覽器啓用緩存至少有兩點顯而易見的好處：（1）減小頁面加載時間；（2）減小服務器負載；

瀏覽器是否使用緩存、緩存多久，是由服務器控制的。準確來講，當瀏覽器請求一個網頁（或者其餘資源）時，服務器發回的響應的「響應頭」部分的某些字段指明瞭有關緩存的關鍵信息。下面看下，HTTP報文中與緩存相關的首部字段：

1. 通用首部字段（就是請求報文和響應報文都能用上的字段）

   

2. 請求首部字段

   

3. 響應首部字段

   

4. 實體首部字段

   

3 瀏覽器緩存機制

根據上面四種類型的首部字段不一樣使用策略，瀏覽器中緩存可分爲強緩存和協商緩存：

1）瀏覽器在加載資源時，先根據這個資源的一些http header判斷它是否命中強緩存，強緩存若是命中，瀏覽器直接從本身的緩存中讀取資源，不會發請求到服務器。好比：某個css文件，若是瀏覽器在加載它所在的網頁時，這個css文件的緩存配置命中了強緩存，瀏覽器就直接從緩存中加載這個css，連請求都不會發送到網頁所在服務器；

2）當強緩存沒有命中的時候，瀏覽器必定會發送一個請求到服務器，經過服務器端依據資源的另一些http header驗證這個資源是否命中協商緩存，若是協商緩存命中，服務器會將這個請求返回，可是不會返回這個資源的數據，而是告訴客戶端能夠直接從緩存中加載這個資源，因而瀏覽器就又會從本身的緩存中去加載這個資源；

3）強緩存與協商緩存的共同點是：若是命中，都是從客戶端緩存中加載資源，而不是從服務器加載資源數據；區別是：強緩存不發請求到服務器，協商緩存會發請求到服務器。

4）當協商緩存也沒有命中的時候，瀏覽器直接從服務器加載資源數據。

3.1 強緩存：Expires&Cache-Control

當瀏覽器對某個資源的請求命中了強緩存時，返回的HTTP狀態爲200，在chrome的開發者工具的network裏面 size會顯示爲from cache，好比：京東的首頁裏就有不少靜態資源配置了強緩存，用chrome打開幾回，再用f12查看network，能夠看到有很多請求就是從緩存中加載的：

強緩存是利用Expires或者Cache-Control這兩個http response header實現的，它們都用來表示資源在客戶端緩存的有效期。

Expires是HTTP 1.0提出的一個表示資源過時時間的header，它描述的是一個絕對時間，由服務器返回，用GMT格式的字符串表示，如：Expires:Thu, 31 Dec 2037 23:55:55 GMT，包含了Expires頭標籤的文件，就說明瀏覽器對於該文件緩存具備很是大的控制權。

例如，一個文件的Expires值是2020年的1月1日，那麼就表明，在2020年1月1日以前，瀏覽器均可以直接使用該文件的本地緩存文件，而沒必要去服務器再次請求該文件，哪怕服務器文件發生了變化。

因此，Expires是優化中最理想的狀況，由於它根本不會產生請求，因此後端也就無需考慮查詢快慢。它的緩存原理，以下：

1. 瀏覽器第一次跟服務器請求一個資源，服務器在返回這個資源的同時，在response的header加上Expires的header，如：

   

2. 瀏覽器在接收到這個資源後，會把這個資源連同全部response header一塊兒緩存下來（因此緩存命中的請求返回的header並非來自服務器，而是來自以前緩存的header）；

3. 瀏覽器再請求這個資源時，先從緩存中尋找，找到這個資源後，拿出它的Expires跟當前的請求時間比較，若是請求時間在Expires指定的時間以前，就能命中緩存，不然就不行；

4. 若是緩存沒有命中，瀏覽器直接從服務器加載資源時，Expires Header在從新加載的時候會被更新；

Expires是較老的強緩存管理header，因爲它是服務器返回的一個絕對時間，在服務器時間與客戶端時間相差較大時，緩存管理容易出現問題，好比：隨意修改下客戶端時間，就能影響緩存命中的結果。因此在HTTP 1.1的時候，提出了一個新的header，就是Cache-Control，這是一個相對時間，在配置緩存的時候，以秒爲單位，用數值表示，如：Cache-Control:max-age=315360000，它的緩存原理是：

1. 瀏覽器第一次跟服務器請求一個資源，服務器在返回這個資源的同時，在response的header加上Cache-Control的header，如：

   

2. 瀏覽器在接收到這個資源後，會把這個資源連同全部response header一塊兒緩存下來；

3. 瀏覽器再請求這個資源時，先從緩存中尋找，找到這個資源後，根據它第一次的請求時間和Cache-Control設定的有效期，計算出一個資源過時時間，再拿這個過時時間跟當前的請求時間比較，若是請求時間在過時時間以前，就能命中緩存，不然就不行；

4. 若是緩存沒有命中，瀏覽器直接從服務器加載資源時，Cache-Control Header在從新加載的時候會被更新；

Cache-Control描述的是一個相對時間，在進行緩存命中的時候，都是利用客戶端時間進行判斷，因此相比較Expires，Cache-Control的緩存管理更有效，安全一些。

這兩個header能夠只啓用一個，也能夠同時啓用，當response header中，Expires和Cache-Control同時存在時，Cache-Control優先級高於Expires：

此外，還能夠爲 Cache-Control 指定 public 或 private 標記。若是使用 private，則表示該資源僅僅屬於發出請求的最終用戶，這將禁止中間服務器（如代理服務器）緩存此類資源。對於包含用戶我的信息的文件（如一個包含用戶名的 HTML 文檔），能夠設置 private，一方面因爲這些緩存對其餘用戶來講沒有任何意義，另外一方面用戶可能不但願相關文件儲存在不受信任的服務器上。須要指出的是，private 並不會使得緩存更加安全，它一樣會傳給中間服務器（若是網站對於傳輸的安全性要求很高，應該使用傳輸層安全措施）。對於 public，則容許全部服務器緩存該資源。一般狀況下，對於全部人均可以訪問的資源（例如網站的 logo、圖片、腳本等），Cache-Control 默認設爲 public 是合理的。

3.2 協商緩存：Last-Modified&Etag

當瀏覽器對某個資源的請求沒有命中強緩存，就會發一個請求到服務器，驗證協商緩存是否命中，若是協商緩存命中，請求響應返回的http狀態爲304而且會顯示一個Not Modified的字符串，好比你打開京東的首頁，按f12打開開發者工具，再按f5刷新頁面，查看network，能夠看到有很多請求就是命中了協商緩存的：

查看單個請求的Response Header，也能看到304的狀態碼和Not Modified的字符串，只要看到這個就可說明這個資源是命中了協商緩存，而後從客戶端緩存中加載的，而不是服務器最新的資源：

協商緩存是利用的是【Last-Modified，If-Modified-Since】和【ETag、If-None-Match】這兩對Header來管理的。

【Last-Modified，If-Modified-Since】的控制緩存的原理，以下：

1. 瀏覽器第一次跟服務器請求一個資源，服務器在返回這個資源的同時，在response的header加上Last-Modified的header，這個header表示這個資源在服務器上的最後修改時間：

   

2. 瀏覽器再次跟服務器請求這個資源時，在request的header上加上If-Modified-Since的header，這個header的值就是上一次請求時返回的Last-Modified的值：

   

3. 服務器再次收到資源請求時，根據瀏覽器傳過來If-Modified-Since和資源在服務器上的最後修改時間判斷資源是否有變化，若是沒有變化則返回304 Not Modified，可是不會返回資源內容；若是有變化，就正常返回資源內容。當服務器返回304 Not Modified的響應時，response header中不會再添加Last-Modified的header，由於既然資源沒有變化，那麼Last-Modified也就不會改變，這是服務器返回304時的response header：

   

4. 瀏覽器收到304的響應後，就會從緩存中加載資源。

5. 若是協商緩存沒有命中，瀏覽器直接從服務器加載資源時，Last-Modified Header在從新加載的時候會被更新，下次請求時，If-Modified-Since會啓用上次返回的Last-Modified值。

【Last-Modified，If-Modified-Since】都是根據服務器時間返回的header，通常來講，在沒有調整服務器時間和篡改客戶端緩存的狀況下，這兩個header配合起來管理協商緩存是很是可靠的，可是有時候也會服務器上資源其實有變化，可是最後修改時間卻沒有變化的狀況，而這種問題又很不容易被定位出來，而當這種狀況出現的時候，就會影響協商緩存的可靠性。因此就有了另一對header來管理協商緩存，這對header就是【ETag、If-None-Match】。它們的緩存管理的方式是：

1. 瀏覽器第一次跟服務器請求一個資源，服務器在返回這個資源的同時，在response的header加上ETag的header，這個header是服務器根據當前請求的資源生成的一個惟一標識，這個惟一標識是一個字符串，只要資源有變化這個串就不一樣，跟最後修改時間沒有關係，因此能很好的補充Last-Modified的問題：

   

2. 瀏覽器再次跟服務器請求這個資源時，在request的header上加上If-None-Match的header，這個header的值就是上一次請求時返回的ETag的值：

   

3. 服務器再次收到資源請求時，根據瀏覽器傳過來If-None-Match和而後再根據資源生成一個新的ETag，若是這兩個值相同就說明資源沒有變化，不然就是有變化；若是沒有變化則返回304 Not Modified，可是不會返回資源內容；若是有變化，就正常返回資源內容。與Last-Modified不同的是，當服務器返回304 Not Modified的響應時，因爲ETag從新生成過，response header中還會把這個ETag返回，即便這個ETag跟以前的沒有變化：

   

4. 瀏覽器收到304的響應後，就會從緩存中加載資源。

Etag和Last-Modified很是類似，都是用來判斷一個參數，從而決定是否啓用緩存。可是ETag相對於Last-Modified也有其優點，能夠更加準確的判斷文件內容是否被修改，從而在實際操做中實用程度也更高。

協商緩存跟強緩存不同，強緩存不發請求到服務器，因此有時候資源更新了瀏覽器還不知道，可是協商緩存會發請求到服務器，因此資源是否更新，服務器確定知道。大部分web服務器都默認開啓協商緩存，並且是同時啓用【Last-Modified，If-Modified-Since】和【ETag、If-None-Match】，好比apache:

若是沒有協商緩存，每一個到服務器的請求，就都得返回資源內容，這樣服務器的性能會極差。

【Last-Modified，If-Modified-Since】和【ETag、If-None-Match】通常都是同時啓用，這是爲了處理Last-Modified不可靠的狀況。有一種場景須要注意：

分佈式系統裏多臺機器間文件的Last-Modified必須保持一致，以避免負載均衡到不一樣機器致使比對失敗；

分佈式系統儘可能關閉掉ETag(每臺機器生成的ETag都會不同）；

好比，京東頁面的資源請求，返回的repsonse header就只有Last-Modified，沒有ETag：

協商緩存須要配合強緩存使用，上面這個截圖中，除了Last-Modified這個header，還有強緩存的相關header，由於若是不啓用強緩存的話，協商緩存根本沒有意義。

4 緩存判斷流程

若是資源已經被瀏覽器緩存下來，在緩存失效以前，再次請求時，默認會先檢查是否命中強緩存，若是強緩存命中則直接讀取緩存，若是強緩存沒有命中則發請求到服務器檢查是否命中協商緩存，若是協商緩存命中，則告訴瀏覽器仍是能夠從緩存讀取，不然才從服務器返回最新的資源。其瀏覽器判斷緩存的詳細流程圖，以下：

5 其餘參考資料

1. 淺談Web緩存
2. 淺談瀏覽器http的緩存機制