理論篇 | 瀏覽器緩存機制

這是我參與8月更文挑戰的第4天，活動詳情查看：8月更文挑戰

前言

網絡層面的性能優化，使用緩存是一個最直接有效的方案。使用緩存能夠減小網絡 IO 消耗，提升訪問速度，效果顯著。所以，認識一下瀏覽器的緩存機制頗有必要。

上圖 Network 面板的截圖中，咱們能夠看到 size 列能夠看到緩存的獲取來源。

瀏覽器緩存機制有四個方面，它們按請求的優先級依次排列以下：

1. Memory Cache
2. Service Worker Cache
3. HTTP Cache
4. Push Cache

Chrome 官方的緩存決策流程圖

其中，HTTP 緩存是最主要、最具表明性的緩存策略，咱們先來認識一下這位 HTTP 緩存機制。

HTTP 緩存機制

HTTP緩存又分爲強緩存和協商緩存，強緩存優先級高於協商緩存，資源沒有命中強緩存，纔會走協商緩存。

強緩存

特徵

• 強緩存由 HTTP 頭中的 Expires 和 Cache-Control 兩個字段控制
• 若是瀏覽器判斷目標資源命中強緩存，則直接從緩存中獲取資源
• 強緩存命中時，返回HTTP狀態碼爲 200

從 expires 到 Cache-Control

• expires 是一個時間戳，若是本地時間小於 expires 設定的過時時間，那麼就直接去緩存中取這個資源。
• 問題：時間戳由服務端生成，客戶端和服務端之間可能存在時間差
• 解決：能夠在 Cache-Control 中配置 max-age，max-age設定的是相對時間長度，表示在時間長度內有效。從而規避 expires 的時差問題。
• Cache-Control 的 max-age 優先級高於 expires
• max-age能夠視做是對 expires 的補位/替換，但若是有向下兼容的訴求，expires 仍是要的。

Cache-Control 的其餘配置項

• s-maxage：僅在代理服務器中生效
• public 與 private：
  • public：既能夠被瀏覽器緩存，也能夠被代理服務器緩存；
  • private：只能被瀏覽器緩存（默認）
• no-store：繞開瀏覽器，直接向服務端去確認該資源是否過時（走協商緩存）
• no-cache：不使用任何緩存策略，直接向服務端請求資源

協商緩存

特徵

• 協商緩存是瀏覽器和服務端合做的緩存策略
• 瀏覽器詢問服務端是否使用緩存，若是服務端響應 304(Not Modify)，即資源未改動，則使用瀏覽器緩存。

Last-Modified

實現

• 啓用協商緩存，首次請求時，響應頭攜帶 Last-Modified（時間戳）返回
• 以後每次請求，帶上 If-Modified-Since ，值爲首次請求時的 Last-Modified的值
• 服務器對比If-Modified-Since和資源的最後修改時間是否一致
  • 若是一致，返回 304
  • 若是不一致，返回完整的響應內容，並在響應頭添加新的 Last-Modified

問題
Last-Modified 存在一些弊端，

• 文件編輯過，內容未修改，但最後修改時間改變了
• 文件內容修改了，但修改速度過快（未滿1s），而 If-Modified-Since 只能檢查到以秒爲最小計量單位的時間差

對於上面兩種場景，Last-Modified 沒法正確判斷資源是否變化。

Etag

爲了解決上述問題，Etag 做爲 Last-Modified 的補充出現了。

• 首次請求時，響應頭攜帶 ETag 返回
• 以後每次請求，攜帶 if-None-Match（值爲ETag的值）
• 當 Etag 和 Last-Modified 同時存在時，以 Etag 爲準

弊端： Etag 生成過程須要服務器額外付出開銷，影響服務端性能。