圖解瀏覽器緩存，教你提升用戶體驗

歡迎你們前往騰訊雲+社區，獲取更多騰訊海量技術實踐乾貨哦~

本文由前端林子發表於雲+社區專欄

瀏覽器緩存，是瀏覽器端保存數據，用於快速讀取或避免重複資源請求的優化機制，有效的緩存使用能夠避免重複的網絡請求和加快頁面速度,從而提升用戶體驗。

一 強緩存

1.1 區分Expires和Cache-Control

以一個接口返回的響應頭爲例：

這裏我畫了張思惟導圖，對Expires和Cache-Control作比較：

具體介紹Expires和Cache-Control：

Expires:

(1)Expires是HTTP1.0的東西，如今默認瀏覽器均默認使用HTTP 1.1，因此它的做用基本忽略；

(2)Expires規定了緩存失效時間（Date爲當前時間），是絕對時間。因爲Expires返回的是一個絕對時間，在服務器時間與客戶端時間相差較大的時候，緩存命中不許確；

Cache-Control：

(1)Cache-Control是HTTP1.1的

(2)Cache-Control的max-age規定了緩存有效時間（2552s)，是相對時間；

(3)若響應頭Expires和Cache-Control同時存在，Cache-Control優先級高於Expires

Cache-Control的經常使用指令：

no-cache：不使用本地緩存，須要使用協商緩存，也就是先與服務器確認緩存是否可用。

no-store：禁用緩存。用於防止重要的信息被無心的發佈。在請求消息中發送將使得請求和響應消息都不使用緩存。

public：其餘用戶也可以使用緩存，適用於公共緩存服務器的狀況。

private：只有特定用戶才能使用緩存，適用於公共緩存服務器的狀況。

max-age：客戶機能夠接收生存期不大於指定時間（以秒爲單位）的響應。

min-fresh客戶機能夠接收響應時間小於當前時間加上指定時間的響應。

max-stale指示客戶機能夠接收超出超時期間的響應消息。若是指定max-stale消息的值，那麼客戶機能夠接收超出超時期指定值以內的響應消息。

注意：no-cache指令並非不緩存，no-cache的意思是能夠緩存，但每次用應該去向服務器驗證緩存是否可用。no-store纔是不緩存內容。

1.2 強緩存的過程

強緩存：瀏覽器直接從本地緩存中獲取數據，不與服務器進行交互。

· 瀏覽器第一次跟服務器請求一個資源，服務器在返回這個資源的同時，在response的header會加上Expires/Cache-Control的header；

· 瀏覽器再請求這個資源時，先從緩存中尋找，找到這個資源後，比較Expires或Cache-Control的max-age字段值作比較, 若是在有效期內，則讀取緩存內容；若緩存已過時，則從新向服務器發送請求；

· header在從新加載的時候會被更新

這裏我畫了兩張圖，瀏覽器第一次請求：

瀏覽器第一次請求

瀏覽器再次請求：

強緩存

對於強緩存，chrome瀏覽器的狀態碼：

200 OK(from disk cache)或是200 OK (from memory cache)

例如：請求某個圖片後，當瀏覽器再次訪問這個圖片時，發現有這個圖片的緩存，且緩存沒過時，因此就使用緩存。

當瀏覽器發現緩存過時後，緩存並不必定不能使用了。好比文件雖然過了有效期，但內容並無發生改變，仍是能夠用緩存數據。因此，這個時候須要與服務器協商，讓服務器判斷本地緩存是否還能使用。那麼又怎麼判斷服務端文件有沒有更新呢？主要有兩種方式：

Last-Modified，If-Modified-since。

二 協商緩存

2.1 區分Last-Modified和If-Modified-Since

以一個返回的接口爲例：

Last-Modified的格式：

Last-Modified: Mon, 17 Sep 2018 12:06:18 GMT

If-Modified-Since的格式：

If-Modified-Since: Mon, 17 Sep 2018 12:06:18 GMT

2.2 Etag是什麼

web服務器響應請求時，告訴瀏覽器當前資源在服務器的惟一標識（生成規則由服務器決定）。Apache中，ETag的值默認是對文件的索引節（INode），大小（Size）和最後修改時間（MTime）進行Hash後獲得的。

2.3 協商緩存的過程

瀏覽器第一次請求：

瀏覽器第一次緩存

瀏覽器再一次請求：

協商緩存

Last-Modified、If-Modified-Since：

· 瀏覽器第一次向服務器請求一個資源，服務器在返回這個資源的同時，在respone的header加上Last-Modified字段，表示該資源在服務器上的最後修改時間；

· 瀏覽器再次向服務器請求這個資源時，在request的header上加上If-Modified-Since字段，這個值就是上一次請求時返回的Last-Modified的值;

·服務器收到資源請求時，比較If-Modified-Since字段值和被請求資源的最後修改時間，若資源最後修改時間較舊，則說明文件沒有修改，返回304 Not Modified, 瀏覽器從緩存中加載資源；若不相同，說明文件被更新，瀏覽器直接從服務器加載資源, 返回200；

·從新加載資源時更新Last-Modified Header

Etag、If-None-Match

· 瀏覽器第一次向服務器請求一個資源，服務器在返回這個資源的同時，在respone的header加上ETag字段；

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

·服務器再次收到資源請求時，再根據資源生成一個新的ETag，與瀏覽器傳過來If-None-Match比較，若是這兩個值相同，則說明資源沒有變化，返回304 Not Modified, 瀏覽器從緩存中加載資源，不然返回200 資源內容。與Last-Modified不同的是，當服務器返回304 Not Modified的響應時，因爲ETag從新生成過，response header中還會把這個ETag返回，即便這個ETag跟以前的沒有變化

2.4 爲何有了Last-Modified，還要用Etag呢？

HTTP1.1中ETag的出現主要是爲了解決幾個Last-Modified比較難解決的問題：

·一些文件也許會週期性的更改，可是他的內容並不改變(僅僅改變的修改時間)，這個時候咱們並不但願客戶端認爲這個文件被修改了，而從新GET；

·某些文件修改很是頻繁，好比在秒如下的時間內進行修改，(比方說1s內修改了N次)，If-Modified-Since能檢查到的粒度是s級的，這種修改沒法判斷(或者說UNIX記錄MTIME只能精確到秒)；

·某些服務器不能精確的獲得文件的最後修改時間。

對於上述情景，利用ETag可以更加準確的控制緩存，由於ETag是服務器自動生成的資源在服務器端的惟一標識符，資源每次變更，都會生成新的ETag值。Last-Modified與ETag是能夠一塊兒使用的，但服務器會優先驗證ETag。

2.5 比較強緩存和協商緩存

基於上文對強緩存和協商緩存過程的解釋，這裏我把強緩存和協商緩存繪製在一張圖裏，方便比較，具體過程能夠參照上文：

http緩存

三 小結

本文主要經過圖解介紹了http的緩存，具體包括強緩存和協商緩存。若有問題，歡迎指正。

相關閱讀
【每日課程推薦】機器學習實戰！快速入門在線廣告業務及CTR相應知識

此文已由做者受權騰訊雲+社區發佈，更多原文請點擊

搜索關注公衆號「雲加社區」，第一時間獲取技術乾貨，關注後回覆1024 送你一份技術課程大禮包！

海量技術實踐經驗，盡在雲加社區！