瀏覽器緩存機制學習總結

最近在做一個考試系統時，由于經常加載試卷或圖片等等靜態資源，抽空學習了一下緩存機制，在此記錄

為什么要使用緩存

1、通過HTTP協議，在客戶端和瀏覽器建立連接時需要消耗時間，而大的響應需要在客戶端和服務器之間進行多次往返通信才能獲得完整的響應，這拖延了瀏覽器可以使用和處理內容的時間。這就增加了訪問服務器的數據和資源的成本，因此利用瀏覽器的緩存機制重用以前獲取的數據就變成了性能優化時需要考慮的事情。
2、流量啊，現在云服務器流量都是收費的（- -玩笑）

瀏覽器緩存機制簡介

一般使用中，緩存策略都是通過http 請求或響應里的header字段定義的，且許多是搭配使用的
各個字段定義詳見 http 緩存 MDN

常用的字段個人看來主要分為兩個部分

• 緩存策略字段
• 緩存校驗字段

接下來依次介紹

緩存策略字段

Pragma（http1.0）,cache-control（http1.1）

Pragma

Pragma：no-cache可以禁用瀏覽器緩存，使得瀏覽器每次都會發起新請求去獲取資源
Pragma的優先級比expires高，如果給Pragma：no-cache且給expires一個未過期的事件，瀏覽器仍會發起新請求
expires時服務端的時間，與客戶端時間可能不一致哦

cache-control（重點）

http1.1新增加的cache-control字段來彌補Pragma的不足，來對緩存策略提供更細粒度的控制，可以定義的值如下
request header 請求頭header可以定義的值：

response header 相應header可以定義的值：

對幾個字段加以解釋

• cache-control：no-cache ，強制瀏覽器不直接使用緩存，每次需要向服務器發起請求校驗緩存有效性
• cache-control：max-age=1000 ，1000秒內，該資源有效，瀏覽器無需再次請求獲取資源（response 200 from cache）
• cache-control：public ，可以被任何中間人（比如中間代理、CDN等）緩存。
• cache-control：private，該響應是專用于某單個用戶的，中間人不能緩存此響應

cache-control優先級高于expirse

對緩存策略進行簡單總結就是：
不會發起請求的場景：

cache-control：max-age在有效期內

當前客戶端時間未超過expirse

需要發起請求驗證緩存是否有效的場景（需要配合if-modified-since || if-none-match），返回304可以在緩存取值：

cache-control：no-cache

cache-control：max-age超出有效期

當前客戶端時間超過expirse

必須發起請求獲取新資源的場景：

cache-control：no-store

緩存校驗字段

last-modifed,e-tag

last-modified

該字段定義了資源上次的修改時間
場景：（cache-control:no-cache）
當客戶端請求相應資源時，服務端會返回last-modified字段
客戶端再次請求相應資源時會帶上if-modified-since:(last-modified)value，
如果資源未改動（資源的last-modified <=if-modified-since）則返回304，
如資源已更新，返回新資源（200），同時更新last-modified的值

如果是cache-control:max-age=?,請求之前還會判斷有效期(可能就無需請求了，直接從瀏覽器緩存獲取)

e-tag

e-tag是服務端對某個資源計算出來的唯一指紋值，如果資源有改動，計算出來的指紋值會變化。
客戶端請求時會帶上之前服務端返回的 if-none-match:e-tag，服務端以指紋值是否相等為依據判斷客戶端的緩存是否有效。
如有效，返回304，如失效，返回200和新資源

e-tag的出現是彌補last-modified的不足

last-modifie只能精確到秒，如一秒內多次更新，則不能獲取最新資源

如果某資源是定期更新的但內容卻可能未改變，

則last-modified每次都會更新而導致重復返回資源，
而e-tag值不會變因為內容不變，所以e-tag在這種場景下高效利用了緩存。

注意

如果服務端相應同時具有last-modified和e-tag，那么下次請求時會帶上兩者

• if-none-match： e-tag；
• if-modified-since： （last-modified）value

且這兩者同時滿足才會返回304，否則返回200。

實例

找個網站請求實例看一下字段我們都理解了沒

如圖這里的這個js資源是直接從http緩存直接加載的，肯定是上次請求的時間與現在相比沒超過max-age。

寫在最后

現在看這張圖應該有點清晰了，這篇作為個人學習總結，許多細節不夠詳盡，實例操作不夠，推薦各位去更加詳盡參考資料中細細品讀。

Reference

• 通過瀏覽器看緩存
• web性能優化:詳說瀏覽器緩存
• 淺談瀏覽器http的緩存機制
• MDN

總結

以上是生活随笔為你收集整理的浏览器缓存机制学习总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。