瀏覽器緩存機制

1、前言

緩存能夠說是性能優化中簡單高效的一種優化方式了。一個優秀的緩存策略能夠縮短網頁請求資源的距離，減小延遲，而且因爲緩存文件能夠重複利用，還能夠減小帶寬，下降網絡負荷。

對於一個數據請求來講，能夠分爲發起網絡請求、後端處理、瀏覽器響應三個步驟。瀏覽器緩存能夠幫助咱們在第一和第三步驟中優化性能。好比說直接使用緩存而不發起請求，或者發起了請求但後端存儲的數據和前端一致，那麼就沒有必要再將數據回傳回來，這樣就減小了響應數據。

接下來的內容中咱們將經過緩存位置、緩存策略以及實際場景應用緩存策略來探討瀏覽器緩存機制(如需獲取思惟導圖，請猛戳GitHub博客)。

推薦一款線上應用實時BUG監控平臺Fundebug，讓天下沒有難寫的bug

2、緩存位置

從緩存位置上來講分爲四種，而且各自有優先級，當依次查找緩存且都沒有命中的時候，纔會去請求網絡。

• Service Worker
• Memory Cache
• Disk Cache
• Push Cache

1. Service Worker

Service Worker 是運行在瀏覽器背後的獨立線程，通常能夠用來實現緩存功能。使用 Service Worker的話，傳輸協議必須爲 HTTPS。由於 Service Worker 中涉及到請求攔截，因此必須使用 HTTPS 協議來保障安全。Service Worker 的緩存與瀏覽器其餘內建的緩存機制不一樣，它可讓咱們自由控制緩存哪些文件、如何匹配緩存、如何讀取緩存，而且緩存是持續性的。

Service Worker 實現緩存功能通常分爲三個步驟：首先須要先註冊 Service Worker，而後監聽到 install 事件之後就能夠緩存須要的文件，那麼在下次用戶訪問的時候就能夠經過攔截請求的方式查詢是否存在緩存，存在緩存的話就能夠直接讀取緩存文件，不然就去請求數據。

當 Service Worker 沒有命中緩存的時候，咱們須要去調用 fetch 函數獲取數據。也就是說，若是咱們沒有在 Service Worker 命中緩存的話，會根據緩存查找優先級去查找數據。可是無論咱們是從 Memory Cache 中仍是從網絡請求中獲取的數據，瀏覽器都會顯示咱們是從 Service Worker 中獲取的內容。

2. Memory Cache

Memory Cache 也就是內存中的緩存，主要包含的是當前中頁面中已經抓取到的資源,例如頁面上已經下載的樣式、腳本、圖片等。讀取內存中的數據確定比磁盤快,內存緩存雖然讀取高效，但是緩存持續性很短，會隨着進程的釋放而釋放。 一旦咱們關閉 Tab 頁面，內存中的緩存也就被釋放了。

那麼既然內存緩存這麼高效，咱們是否是能讓數據都存放在內存中呢？ 這是不可能的。計算機中的內存必定比硬盤容量小得多，操做系統須要精打細算內存的使用，因此能讓咱們使用的內存必然很少。

當咱們訪問過頁面之後，再次刷新頁面，能夠發現不少數據都來自於內存緩存

內存緩存中有一塊重要的緩存資源是preloader相關指令（例如<link rel="prefetch">）下載的資源。總所周知preloader的相關指令已是頁面優化的常見手段之一，它能夠一邊解析js/css文件，一邊網絡請求下一個資源。

須要注意的事情是，內存緩存在緩存資源時並不關心返回資源的HTTP緩存頭Cache-Control是什麼值，同時資源的匹配也並不是僅僅是對URL作匹配，還可能會對Content-Type，CORS等其餘特徵作校驗。

3. Disk Cache

Disk Cache 也就是存儲在硬盤中的緩存，讀取速度慢點，可是什麼都能存儲到磁盤中，比之 Memory Cache 勝在容量和存儲時效性上。

在全部瀏覽器緩存中，Disk Cache 覆蓋面基本是最大的。它會根據 HTTP Herder 中的字段判斷哪些資源須要緩存，哪些資源能夠不請求直接使用，哪些資源已通過期須要從新請求。而且即便在跨站點的狀況下，相同地址的資源一旦被硬盤緩存下來，就不會再次去請求數據。絕大部分的緩存都來自 Disk Cache，關於 HTTP 的協議頭中的緩存字段，咱們會在下文進行詳細介紹。

瀏覽器會把哪些文件丟進內存中？哪些丟進硬盤中？

關於這點，網上說法不一，不過如下觀點比較靠得住：

• 對於大文件來講，大機率是不存儲在內存中的，反之優先
• 當前系統內存使用率高的話，文件優先存儲進硬盤

4. Push Cache

Push Cache（推送緩存）是 HTTP/2 中的內容，當以上三種緩存都沒有命中時，它纔會被使用。它只在會話（Session）中存在，一旦會話結束就被釋放，而且緩存時間也很短暫，在Chrome瀏覽器中只有5分鐘左右，同時它也並不是嚴格執行HTTP頭中的緩存指令。

Push Cache 在國內可以查到的資料不多，也是由於 HTTP/2 在國內不夠普及。這裏推薦閱讀Jake Archibald的 HTTP/2 push is tougher than I thought 這篇文章，文章中的幾個結論：

• 全部的資源都能被推送，而且可以被緩存,可是 Edge 和 Safari 瀏覽器支持相對比較差
• 能夠推送 no-cache 和 no-store 的資源
• 一旦鏈接被關閉，Push Cache 就被釋放
• 多個頁面可使用同一個HTTP/2的鏈接，也就可使用同一個Push Cache。這主要仍是依賴瀏覽器的實現而定，出於對性能的考慮，有的瀏覽器會對相同域名但不一樣的tab標籤使用同一個HTTP鏈接。
• Push Cache 中的緩存只能被使用一次
• 瀏覽器能夠拒絕接受已經存在的資源推送
• 你能夠給其餘域名推送資源

若是以上四種緩存都沒有命中的話，那麼只能發起請求來獲取資源了。

那麼爲了性能上的考慮，大部分的接口都應該選擇好緩存策略，一般瀏覽器緩存策略分爲兩種：強緩存和協商緩存，而且緩存策略都是經過設置 HTTP Header 來實現的。

3、緩存過程分析

瀏覽器與服務器通訊的方式爲應答模式，便是：瀏覽器發起HTTP請求 – 服務器響應該請求，那麼瀏覽器怎麼肯定一個資源該不應緩存，如何去緩存呢？瀏覽器第一次向服務器發起該請求後拿到請求結果後，將請求結果和緩存標識存入瀏覽器緩存，瀏覽器對於緩存的處理是根據第一次請求資源時返回的響應頭來肯定的。具體過程以下圖：

由上圖咱們能夠知道：

• 瀏覽器每次發起請求，都會先在瀏覽器緩存中查找該請求的結果以及緩存標識

• 瀏覽器每次拿到返回的請求結果都會將該結果和緩存標識存入瀏覽器緩存中

以上兩點結論就是瀏覽器緩存機制的關鍵，它確保了每一個請求的緩存存入與讀取，只要咱們再理解瀏覽器緩存的使用規則，那麼全部的問題就迎刃而解了，本文也將圍繞着這點進行詳細分析。爲了方便你們理解，這裏咱們根據是否須要向服務器從新發起HTTP請求將緩存過程分爲兩個部分，分別是強緩存和協商緩存。

4、強緩存

強緩存：不會向服務器發送請求，直接從緩存中讀取資源，在chrome控制檯的Network選項中能夠看到該請求返回200的狀態碼，而且Size顯示from disk cache或from memory cache。強緩存能夠經過設置兩種 HTTP Header 實現：Expires 和 Cache-Control。

1. Expires

緩存過時時間，用來指定資源到期的時間，是服務器端的具體的時間點。也就是說，Expires=max-age + 請求時間，須要和Last-modified結合使用。Expires是Web服務器響應消息頭字段，在響應http請求時告訴瀏覽器在過時時間前瀏覽器能夠直接從瀏覽器緩存取數據，而無需再次請求。

Expires 是 HTTP/1 的產物，受限於本地時間，若是修改了本地時間，可能會形成緩存失效。Expires: Wed, 22 Oct 2018 08:41:00 GMT表示資源會在 Wed, 22 Oct 2018 08:41:00 GMT 後過時，須要再次請求。

2.Cache-Control

在HTTP/1.1中，Cache-Control是最重要的規則，主要用於控制網頁緩存。好比當Cache-Control:max-age=300時，則表明在這個請求正確返回時間（瀏覽器也會記錄下來）的5分鐘內再次加載資源，就會命中強緩存。

Cache-Control 能夠在請求頭或者響應頭中設置，而且能夠組合使用多種指令：

public：全部內容都將被緩存（客戶端和代理服務器均可緩存）。具體來講響應可被任何中間節點緩存，如 Browser <-- proxy1 <-- proxy2 <-- Server，中間的proxy能夠緩存資源，好比下次再請求同一資源proxy1直接把本身緩存的東西給 Browser 而再也不向proxy2要。

private：全部內容只有客戶端能夠緩存，Cache-Control的默認取值。具體來講，表示中間節點不容許緩存，對於Browser <-- proxy1 <-- proxy2 <-- Server，proxy 會老老實實把Server 返回的數據發送給proxy1,本身不緩存任何數據。當下次Browser再次請求時proxy會作好請求轉發而不是自做主張給本身緩存的數據。 no-cache：客戶端緩存內容，是否使用緩存則須要通過協商緩存來驗證決定。表示不使用 Cache-Control的緩存控制方式作前置驗證，而是使用 Etag 或者Last-Modified字段來控制緩存。須要注意的是，no-cache這個名字有一點誤導。設置了no-cache以後，並非說瀏覽器就再也不緩存數據，只是瀏覽器在使用緩存數據時，須要先確認一下數據是否還跟服務器保持一致。

no-store：全部內容都不會被緩存，即不使用強制緩存，也不使用協商緩存

max-age：max-age=xxx (xxx is numeric)表示緩存內容將在xxx秒後失效

s-maxage（單位爲s)：同max-age做用同樣，只在代理服務器中生效（好比CDN緩存）。好比當s-maxage=60時，在這60秒中，即便更新了CDN的內容，瀏覽器也不會進行請求。max-age用於普通緩存，而s-maxage用於代理緩存。s-maxage的優先級高於max-age。若是存在s-maxage，則會覆蓋掉max-age和Expires header。

max-stale：能容忍的最大過時時間。max-stale指令標示了客戶端願意接收一個已通過期了的響應。若是指定了max-stale的值，則最大容忍時間爲對應的秒數。若是沒有指定，那麼說明瀏覽器願意接收任何age的響應（age表示響應由源站生成或確認的時間與當前時間的差值）。

min-fresh：可以容忍的最小新鮮度。min-fresh標示了客戶端不肯意接受新鮮度很少於當前的age加上min-fresh設定的時間之和的響應。

從圖中咱們能夠看到，咱們能夠將多個指令配合起來一塊兒使用，達到多個目的。好比說咱們但願資源能被緩存下來，而且是客戶端和代理服務器都能緩存，還能設置緩存失效時間等等。

3.Expires和Cache-Control二者對比

其實這二者差異不大，區別就在於 Expires 是http1.0的產物，Cache-Control是http1.1的產物，二者同時存在的話，Cache-Control優先級高於Expires；在某些不支持HTTP1.1的環境下，Expires就會發揮用處。因此Expires實際上是過期的產物，現階段它的存在只是一種兼容性的寫法。 強緩存判斷是否緩存的依據來自因而否超出某個時間或者某個時間段，而不關心服務器端文件是否已經更新，這可能會致使加載文件不是服務器端最新的內容，那咱們如何獲知服務器端內容是否已經發生了更新呢？此時咱們須要用到協商緩存策略。

5、協商緩存

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

• 協商緩存生效，返回304和Not Modified

• 協商緩存失效，返回200和請求結果

協商緩存能夠經過設置兩種 HTTP Header 實現：Last-Modified 和 ETag 。

1.Last-Modified和If-Modified-Since

瀏覽器在第一次訪問資源時，服務器返回資源的同時，在response header中添加 Last-Modified的header，值是這個資源在服務器上的最後修改時間，瀏覽器接收後緩存文件和header；

Last-Modified: Fri, 22 Jul 2016 01:47:00 GMT

瀏覽器下一次請求這個資源，瀏覽器檢測到有 Last-Modified這個header，因而添加If-Modified-Since這個header，值就是Last-Modified中的值；服務器再次收到這個資源請求，會根據 If-Modified-Since 中的值與服務器中這個資源的最後修改時間對比，若是沒有變化，返回304和空的響應體，直接從緩存讀取，若是If-Modified-Since的時間小於服務器中這個資源的最後修改時間，說明文件有更新，因而返回新的資源文件和200

可是 Last-Modified 存在一些弊端：

• 若是本地打開緩存文件，即便沒有對文件進行修改，但仍是會形成 Last-Modified 被修改，服務端不能命中緩存致使發送相同的資源
• 由於 Last-Modified 只能以秒計時，若是在不可感知的時間內修改完成文件，那麼服務端會認爲資源仍是命中了，不會返回正確的資源

既然根據文件修改時間來決定是否緩存尚有不足，可否能夠直接根據文件內容是否修改來決定緩存策略？因此在 HTTP / 1.1 出現了 ETag 和If-None-Match

2. ETag和If-None-Match

Etag是服務器響應請求時，返回當前資源文件的一個惟一標識(由服務器生成)，只要資源有變化，Etag就會從新生成。瀏覽器在下一次加載資源向服務器發送請求時，會將上一次返回的Etag值放到request header裏的If-None-Match裏，服務器只須要比較客戶端傳來的If-None-Match跟本身服務器上該資源的ETag是否一致，就能很好地判斷資源相對客戶端而言是否被修改過了。若是服務器發現ETag匹配不上，那麼直接以常規GET 200回包形式將新的資源（固然也包括了新的ETag）發給客戶端；若是ETag是一致的，則直接返回304知會客戶端直接使用本地緩存便可。

3. 二者之間對比：

• 首先在精確度上，Etag要優於Last-Modified。

Last-Modified的時間單位是秒，若是某個文件在1秒內改變了屢次，那麼他們的Last-Modified其實並無體現出來修改，可是Etag每次都會改變確保了精度；若是是負載均衡的服務器，各個服務器生成的Last-Modified也有可能不一致。

• 第二在性能上，Etag要遜於Last-Modified，畢竟Last-Modified只須要記錄時間，而Etag須要服務器經過算法來計算出一個hash值。
• 第三在優先級上，服務器校驗優先考慮Etag

6、緩存機制

強制緩存優先於協商緩存進行，若強制緩存(Expires和Cache-Control)生效則直接使用緩存，若不生效則進行協商緩存(Last-Modified / If-Modified-Since和Etag / If-None-Match)，協商緩存由服務器決定是否使用緩存，若協商緩存失效，那麼表明該請求的緩存失效，返回200，從新返回資源和緩存標識，再存入瀏覽器緩存中；生效則返回304，繼續使用緩存。具體流程圖以下：

看到這裏，不知道你是否存在這樣一個疑問:若是什麼緩存策略都沒設置，那麼瀏覽器會怎麼處理？

對於這種狀況，瀏覽器會採用一個啓發式的算法，一般會取響應頭中的 Date 減去 Last-Modified 值的 10% 做爲緩存時間。

7、實際場景應用緩存策略

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 等) 均採用這個模式。

8、用戶行爲對瀏覽器緩存的影響

所謂用戶行爲對瀏覽器緩存的影響，指的就是用戶在瀏覽器如何操做時，會觸發怎樣的緩存策略。主要有 3 種：

• 打開網頁，地址欄輸入地址： 查找 disk cache 中是否有匹配。若有則使用；如沒有則發送網絡請求。
• 普通刷新 (F5)：由於 TAB 並無關閉，所以 memory cache 是可用的，會被優先使用(若是匹配的話)。其次纔是 disk cache。
• 強制刷新 (Ctrl + F5)：瀏覽器不使用緩存，所以發送的請求頭部均帶有 Cache-control: no-cache(爲了兼容，還帶了 Pragma: no-cache),服務器直接返回 200 和最新內容。

參考文章

• 淺談web緩存
• web緩存機制
• 完全理解瀏覽器的緩存機制
• 前端面試之道
• 一文讀懂前端緩存 -A Tale of Four Caches
• HTTP/2 push is tougher than I thought
• 設計一個無懈可擊的瀏覽器緩存方案：關於思路，細節，ServiceWorker，以及HTTP/2

關於Fundebug

Fundebug專一於JavaScript、微信小程序、微信小遊戲、支付寶小程序、React Native、Node.js和Java線上應用實時BUG監控。 自從2016年雙十一正式上線，Fundebug累計處理了9億+錯誤事件，付費客戶有Google、360、金山軟件、百姓網等衆多品牌企業。歡迎你們免費試用！