一．前言

首先我們要知道的是，為什麼作為一個前端開發人員要深入理解浏覽器緩存機制？因為浏覽器緩存機制會直接影響前端性能問題。項目中使用好了緩存，對整體項目性能來說有很大的幫助。比如使用網頁後退功能的時候，會發現網頁加載的特别快，體驗感非常好，這就是浏覽器緩存給用戶帶來的好處。

一個好的緩存策略可以縮短網頁請求資源的距離，減少延遲，并且由于緩存文件可以重複利用，還可以減少帶寬，降低網絡負荷。

對于一個數據請求來說需要三個步驟：發起網絡請求、後端處理數據、浏覽器響應數據。對浏覽器來說，它可以從第一步驟和第三步驟對緩存進行優化處理。例如直接使用緩存而不發起請求，或者發起了請求但後端存儲的數據和前端一緻，那麼就沒有必要再将數據回傳回來，這樣就減少了響應數據時間，對用戶來說可以很快從浏覽器看到響應數據，用戶體驗感極佳。

接下來的内容會通過緩存策略和實際場景應用緩存策略來探讨緩存機制。

二．緩存策略

我們知道浏覽器與服務器通信的方式為應答模式，也就是：浏覽器發起HTTP請求 – 服務器響應該請求，那麼浏覽器怎麼确定一個資源該不該緩存，如何去緩存呢？可以分為如下步驟：

•浏覽器向服務器發送請求，請求資源；

•服務器返回資源并通過響應頭決定緩存策略；

•浏覽器根據響應頭的策略決定是否緩存資源（假設為是），就會将響應頭與資源一同緩存下來；

•在浏覽器再次請求并命中資源的時候，此時浏覽器會檢查上次緩存的緩存策略，根據策略的不同、是否過期等判斷是直接讀取本地緩存還是與服務器協商緩存。

浏覽器對于緩存的處理是根據第一次請求資源時返回的響應頭來确定的。具體過程如下圖：

以上内容描述就引出了浏覽器緩存的兩種緩存機制，為了讀者更容易理解，本文章通過是否需要重新向服務器發送http請求将緩存過程分為兩大部分，即強緩存和協商緩存。

強緩存

強緩存主要使用Expires、Cache-Control 兩個頭字段，兩者同時存在時Cache-Control 優先級更高。當命中強緩存的時候，客戶端不會再請求，直接從緩存中讀取内容，并返回HTTP狀态碼200。以下将對兩header字段進行詳細描述，幫助前端開發人員快速理解其作用。

Expires：響應頭，代表該資源的過期時間。此字段是http1.0提出的一個表示資源過期時間的header，它描述的是一個絕對時間，由服務器返回，但是基于此字段受限于本地時間，如果修改了本地時間，可能會造成緩存失效。

當客戶端請求服務器的時候，服務器會返回資源的同時還會帶上響應頭Expires，表示資源的過期具體時間，如果客戶端在過期時間之前再次獲取該資源，就不需要再請求服務器了，可以直接在緩存裡面拿到數據。

由以上描述我們可以得出：在過期時間以内的話，我們可以直接獲取緩存資源，為用戶節省了很多流量，同時也減少了服務器重複讀取磁盤帶來的壓力；但也能看出來此字段有一個很大的弊端，就是它返回的是服務器的時間，然而判斷的卻是客戶端的時間，假如用戶改變客戶端的時間，導緻緩存時間判斷不準确，進而緩存失效。因此也就引出了Cache-Control字段。

Cache-Control：請求/響應頭，緩存控制字段，精确控制緩存策略。此字段出現于http 1.1，優先級高于Expires，表示的是相對時間。

Cache-Control既能出現在請求頭又能出現在響應頭，其不同的值代表不同的意思，下面我們具體分析下此字段常用參數設置。

•max-age: 表示服務器端告知客戶端浏覽器響應資源的過期時長。

•s-maxage:對于大型架構的項目通常會涉及使用各種代理服務器的情況，這就需要考慮緩存在代理服務器上的有效性問題，這邊是s-maxage存在的意義，它表示緩存在代理服務器中的過期時長，且僅當設置了public屬性值時才是有效的。

•no-cache：不使用本地強緩存。需要使用緩存協商。

•no-store：直接禁止浏覽器緩存數據，每次用戶請求該資源，都會向服務器發送一個請求，每次都會下載完整的資源，此屬性與no-cache為互斥屬性。

•public：可以被所有的用戶緩存，包括終端用戶和中間代理服務器。·private：隻能被終端用戶的浏覽器緩存，不允許中間緩存代理進行緩存，默認取值。

由以上分析我們可以看出來，實際項目中，隻要設置Cache-Control屬性值完全能達到浏覽器緩存的目的。于此得出的結論：在緩存有效期内命中緩存，浏覽器會直接讀取本地的緩存資源，當緩存過期之後會與服務器進行協商。

協商緩存就是強制緩存失效後，浏覽器攜帶緩存标識向服務器發起請求，由服務器根據緩存标識決定是否使用緩存的過程，主要有以下兩種情況：

•協商緩存生效，如果緩存和服務端資源的最新版本是一緻的，那麼就無需再次下載該資源，服務端直接返回304 Not Modified 狀态碼。

•協商緩存失效，如果服務器發現浏覽器中的緩存已經是舊版本了，那麼服務器就會把最新資源的完整内容返回給浏覽器，狀态碼就是 “200 ok”。

協商緩存主要有四個頭字段，它們兩兩組合配合使用，If-Modified-Since 和 Last-Modified一組，Etag 和 If-None-Match一組，當同時存在的時候會以Etag 和 If-None-Match為主。當命中協商緩存的時候，服務器會返回HTTP狀态碼304，讓客戶端直接從本地緩存裡面讀取文件。

If-Modified-Since：請求頭，資源最近修改時間，由浏覽器告訴服務器。其實就是第一次訪問服務端返回的Last-Modified的值。

Last-Modified：響應頭，資源最近修改時間，由服務器告訴浏覽器。

Etag：響應頭，資源标識，由服務器告訴浏覽器。

If-None-Match：請求頭，緩存資源标識，由浏覽器告訴服務器。其實就是第一次訪問服務端返回的Etag的值。

If-Modified-Since 和 Last-Modified：

當客戶端首次請求資源的時候，服務器會把資源的最新修改時間 Last-Modified通過響應頭發送給客戶端，當再次發送請求時，客戶端将服務器返回的修改時間放在請求頭 If-Modified-Since發送給服務器，服務器再跟服務器上的對應資源進⾏⽐對，如果服務器的資源更新，那麼返回最新的資源，返回200狀态碼，當服務器資源跟客戶端請求的時間⼀緻，證明客戶端的資源是最新的，返回304狀态碼，就使用本地緩存，不需要再次發送請求。

以上内容我們可以看出使用If-Modified-Since 和 Last-Modified帶來的好處是：當緩存有效時服務器不會返回資源給到客戶端，而是直接返回304狀态碼，讓客戶端直接從緩存中取資源，這樣就大大節省了流量和帶寬，并極大的減少了服務器的壓力；但是也存在一些弊端：Last-Modified字段值隻能精确到秒，假如在同一時間既修改文件又獲取文件的話，此時客戶端是獲取不到最新文件的。

Etag 和 If-None-Match：

ETag的流程跟Last-Modified是類似的，區别就在于ETag是根據資源内容進⾏hash，⽣成⼀個信息摘要，隻要資源内容有變化，這個摘要就會發⽣變化，通過這個摘要信息⽐對，即可确定客戶端的緩存資源是否為最新，這⽐Last-Modified的精确度要更⾼。

當客戶端第一次請求服務器的時候，服務端會返回一個Etag響應頭。客戶端請求服務器的時候會帶上If-None-Match請求頭字段，該字段的值就是服務器返回的Etag的值。服務器接收到請求後會比較這兩個值是否一樣，一樣就返回304，讓客戶端從緩存中讀取，不一樣就會返回新文件給客戶端并更新Etag響應頭字段的值。

由此分析我們可以看出來，使用Etag 和 If-None-Match的好處：（除上述If-Modified-Since 和 Last-Modified的優點外）解決了一秒内修改并讀取的問題。

三．實際場景應用緩存策略

1. 頻繁變動的資源

Cache-Control: no-cache

基于我們政務開放平台項目來說，考慮到用戶接收資源等待時間，我們可以把頻繁變動的資源通過優化緩存方案，給到用戶更好的體驗感。首先需要使用 Cache-Control:no-cache 使浏覽器每次都請求服務器，然後配合 ETag 或者 Last-Modified 來驗證資源是否有效。這樣的做法雖然不能節省請求數量，但是能顯著減少響應數據大小。

2. 不常變化的資源

Cache-Control: max-age=31536000

基于我們政務開放平台項目來說，對于不經常需要變更的資源處理方式是，給它們的 Cache-Control 配置一個很大的 max-age=31536000 (一年)，這樣浏覽器之後請求相同的 URL 會命中強制緩存。同時為了解決資源更新的問題，需要在文件名（或路徑）中添加hash，版本号等動态字符，之後更改動态字符，從而達到更改引用 URL 的目的，讓之前的強制緩存失效 (其實并未立即失效，隻是不再使用了而已)。在線提供的類庫 (如 jquery-3.3.1.min.js, lodash.min.js 等) 均采用這個模式。

已上内容為本次文章探讨的浏覽器緩存機制，詳細介紹了強緩存和協商緩存的原理知識，希望本文章可以幫助更多的前端開發者對浏覽器緩存機制有更透徹的認識并應用到自己的實際項目中。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!