緩存可以說(shuō)是性能優(yōu)化中簡(jiǎn)單高效的一種優(yōu)化方式了。一個(gè)優(yōu)秀的緩存策略可以縮短網(wǎng)頁(yè)請求資源的距離，減少延遲，并且由于緩存文件可以重復利用，還可以減少帶寬，降低網(wǎng)絡(luò )負荷。
對于一個(gè)數據請求來(lái)說(shuō)，可以分為發(fā)起網(wǎng)絡(luò )請求、后端處理、瀏覽器響應三個(gè)步驟。瀏覽器緩存可以幫助我們在第一和第三步驟中優(yōu)化性能。比如說(shuō)直接使用緩存而不發(fā)起請求，或者發(fā)起了請求但后端存儲的數據和前端一致，那么就沒(méi)有必要再將數據回傳回來(lái)，這樣就減少了響應數據。
接下來(lái)的內容中我們將通過(guò)緩存位置、緩存策略以及實(shí)際場(chǎng)景應用緩存策略來(lái)探討瀏覽器緩存機制。
從緩存位置上來(lái)說(shuō)分為四種，并且各自有優(yōu)先級，當依次查找緩存且都沒(méi)有命中的時(shí)候，才會(huì )去請求網(wǎng)絡(luò )。
Service Worker
Memory Cache
Disk Cache
Push Cache
Service Worker 是運行在瀏覽器背后的獨立線(xiàn)程，一般可以用來(lái)實(shí)現緩存功能。使用 Service Worker的話(huà)，傳輸協(xié)議必須為 HTTPS。因為 Service Worker 中涉及到請求攔截，所以必須使用 HTTPS 協(xié)議來(lái)保障安全。Service Worker 的緩存與瀏覽器其他內建的緩存機制不同，它可以讓我們自由控制緩存哪些文件、如何匹配緩存、如何讀取緩存，并且緩存是持續性的。
Service Worker 實(shí)現緩存功能一般分為三個(gè)步驟：首先需要先注冊 Service Worker，然后監聽(tīng)到 install 事件以后就可以緩存需要的文件，那么在下次用戶(hù)訪(fǎng)問(wèn)的時(shí)候就可以通過(guò)攔截請求的方式查詢(xún)是否存在緩存，存在緩存的話(huà)就可以直接讀取緩存文件，否則就去請求數據。
當 Service Worker 沒(méi)有命中緩存的時(shí)候，我們需要去調用 fetch 函數獲取數據。也就是說(shuō)，如果我們沒(méi)有在 Service Worker 命中緩存的話(huà)，會(huì )根據緩存查找優(yōu)先級去查找數據。但是不管我們是從 Memory Cache 中還是從網(wǎng)絡(luò )請求中獲取的數據，瀏覽器都會(huì )顯示我們是從 Service Worker 中獲取的內容。
Memory Cache 也就是內存中的緩存，主要包含的是當前中頁(yè)面中已經(jīng)抓取到的資源,例如頁(yè)面上已經(jīng)下載的樣式、腳本、圖片等。讀取內存中的數據肯定比磁盤(pán)快,內存緩存雖然讀取高效，可是緩存持續性很短，會(huì )隨著(zhù)進(jìn)程的釋放而釋放。 一旦我們關(guān)閉 Tab 頁(yè)面，內存中的緩存也就被釋放了。
那么既然內存緩存這么高效，我們是不是能讓數據都存放在內存中呢？這是不可能的。計算機中的內存一定比硬盤(pán)容量小得多，操作系統需要精打細算內存的使用，所以能讓我們使用的內存必然不多。
當我們訪(fǎng)問(wèn)過(guò)頁(yè)面以后，再次刷新頁(yè)面，可以發(fā)現很多數據都來(lái)自于內存緩存。
內存緩存中有一塊重要的緩存資源是preloader相關(guān)指令（例如 <linkrel='prefetch'>）下載的資源。總所周知preloader的相關(guān)指令已經(jīng)是頁(yè)面優(yōu)化的常見(jiàn)手段之一，它可以一邊解析js/css文件，一邊網(wǎng)絡(luò )請求下一個(gè)資源。
需要注意的事情是，內存緩存在緩存資源時(shí)并不關(guān)心返回資源的HTTP緩存頭Cache-Control是什么值，同時(shí)資源的匹配也并非僅僅是對URL做匹配，還可能會(huì )對Content-Type，CORS等其他特征做校驗。
Disk Cache 也就是存儲在硬盤(pán)中的緩存，讀取速度慢點(diǎn)，但是什么都能存儲到磁盤(pán)中，比之 Memory Cache 勝在容量和存儲時(shí)效性上。
在所有瀏覽器緩存中，Disk Cache 覆蓋面基本是最大的。它會(huì )根據 HTTP Herder 中的字段判斷哪些資源需要緩存，哪些資源可以不請求直接使用，哪些資源已經(jīng)過(guò)期需要重新請求。并且即使在跨站點(diǎn)的情況下，相同地址的資源一旦被硬盤(pán)緩存下來(lái)，就不會(huì )再次去請求數據。絕大部分的緩存都來(lái)自 Disk Cache，關(guān)于 HTTP 的協(xié)議頭中的緩存字段，我們會(huì )在下文進(jìn)行詳細介紹。
瀏覽器會(huì )把哪些文件丟進(jìn)內存中？哪些丟進(jìn)硬盤(pán)中？關(guān)于這點(diǎn)，網(wǎng)上說(shuō)法不一，不過(guò)以下觀(guān)點(diǎn)比較靠得?。?/span>
對于大文件來(lái)說(shuō)，大概率是不存儲在內存中的，反之優(yōu)先
當前系統內存使用率高的話(huà)，文件優(yōu)先存儲進(jìn)硬盤(pán)
Push Cache（推送緩存）是 HTTP/2 中的內容，當以上三種緩存都沒(méi)有命中時(shí)，它才會(huì )被使用。它只在會(huì )話(huà)（Session）中存在，一旦會(huì )話(huà)結束就被釋放，并且緩存時(shí)間也很短暫，在Chrome瀏覽器中只有5分鐘左右，同時(shí)它也并非嚴格執行HTTP頭中的緩存指令。
Push Cache 在國內能夠查到的資料很少，也是因為 HTTP/2 在國內不夠普及。這里推薦閱讀 JakeArchibald的 HTTP/2 push is tougher than I thought 這篇文章，文章中的幾個(gè)結論：
所有的資源都能被推送，并且能夠被緩存,但是 Edge 和 Safari 瀏覽器支持相對比較差
可以推送 no-cache 和 no-store 的資源
一旦連接被關(guān)閉，Push Cache 就被釋放
多個(gè)頁(yè)面可以使用同一個(gè)HTTP/2的連接，也就可以使用同一個(gè)Push Cache。這主要還是依賴(lài)瀏覽器的實(shí)現而定，出于對性能的考慮，有的瀏覽器會(huì )對相同域名但不同的tab標簽使用同一個(gè)HTTP連接。
Push Cache 中的緩存只能被使用一次
瀏覽器可以拒絕接受已經(jīng)存在的資源推送
你可以給其他域名推送資源
如果以上四種緩存都沒(méi)有命中的話(huà)，那么只能發(fā)起請求來(lái)獲取資源了。
那么為了性能上的考慮，大部分的接口都應該選擇好緩存策略，通常瀏覽器緩存策略分為兩種：強緩存和協(xié)商緩存，并且緩存策略都是通過(guò)設置 HTTP Header 來(lái)實(shí)現的。
瀏覽器與服務(wù)器通信的方式為應答模式，即是：瀏覽器發(fā)起HTTP請求 – 服務(wù)器響應該請求，那么瀏覽器怎么確定一個(gè)資源該不該緩存，如何去緩存呢？瀏覽器第一次向服務(wù)器發(fā)起該請求后拿到請求結果后，將請求結果和緩存標識存入瀏覽器緩存，瀏覽器對于緩存的處理是根據第一次請求資源時(shí)返回的響應頭來(lái)確定的。具體過(guò)程如下圖：
由上圖我們可以知道：
瀏覽器每次發(fā)起請求，都會(huì )先在瀏覽器緩存中查找該請求的結果以及緩存標識
瀏覽器每次拿到返回的請求結果都會(huì )將該結果和緩存標識存入瀏覽器緩存中
以上兩點(diǎn)結論就是瀏覽器緩存機制的關(guān)鍵，它確保了每個(gè)請求的緩存存入與讀取，只要我們再理解瀏覽器緩存的使用規則，那么所有的問(wèn)題就迎刃而解了，本文也將圍繞著(zhù)這點(diǎn)進(jìn)行詳細分析。為了方便大家理解，這里我們根據是否需要向服務(wù)器重新發(fā)起HTTP請求將緩存過(guò)程分為兩個(gè)部分，分別是強緩存和協(xié)商緩存。
強緩存：不會(huì )向服務(wù)器發(fā)送請求，直接從緩存中讀取資源，在chrome控制臺的Network選項中可以看到該請求返回200的狀態(tài)碼，并且Size顯示from disk cache或from memory cache。強緩存可以通過(guò)設置兩種 HTTP Header 實(shí)現：Expires 和 Cache-Control。
緩存過(guò)期時(shí)間，用來(lái)指定資源到期的時(shí)間，是服務(wù)器端的具體的時(shí)間點(diǎn)。也就是說(shuō)，Expires=max-age + 請求時(shí)間，需要和Last-modified結合使用。Expires是Web服務(wù)器響應消息頭字段，在響應http請求時(shí)告訴瀏覽器在過(guò)期時(shí)間前瀏覽器可以直接從瀏覽器緩存取數據，而無(wú)需再次請求。
Expires 是 HTTP/1 的產(chǎn)物，受限于本地時(shí)間，如果修改了本地時(shí)間，可能會(huì )造成緩存失效。
Expires:Wed,22Oct201808:41:00GMT表示資源會(huì )在 Wed, 22 Oct 2018 08:41:00 GMT 后過(guò)期，需要再次請求。
在HTTP/1.1中，Cache-Control是最重要的規則，主要用于控制網(wǎng)頁(yè)緩存。比如當 Cache-Control:max-age=300時(shí)，則代表在這個(gè)請求正確返回時(shí)間（瀏覽器也會(huì )記錄下來(lái)）的5分鐘內再次加載資源，就會(huì )命中強緩存。
Cache-Control 可以在請求頭或者響應頭中設置，并且可以組合使用多種指令：
public：所有內容都將被緩存（客戶(hù)端和代理服務(wù)器都可緩存）。具體來(lái)說(shuō)響應可被任何中間節點(diǎn)緩存，如 Browser <-- proxy1 <-- proxy2 <-- Server，中間的proxy可以緩存資源，比如下次再請求同一資源proxy1直接把自己緩存的東西給 Browser 而不再向proxy2要。
private：所有內容只有客戶(hù)端可以緩存，Cache-Control的默認取值。具體來(lái)說(shuō)，表示中間節點(diǎn)不允許緩存，對于Browser <-- proxy1 <-- proxy2 <-- Server，proxy 會(huì )老老實(shí)實(shí)把Server 返回的數據發(fā)送給proxy1,自己不緩存任何數據。當下次Browser再次請求時(shí)proxy會(huì )做好請求轉發(fā)而不是自作主張給自己緩存的數據。
no-cache：客戶(hù)端緩存內容，是否使用緩存則需要經(jīng)過(guò)協(xié)商緩存來(lái)驗證決定。表示不使用 Cache-Control的緩存控制方式做前置驗證，而是使用 Etag 或者Last-Modified字段來(lái)控制緩存。需要注意的是，no-cache這個(gè)名字有一點(diǎn)誤導。設置了no-cache之后，并不是說(shuō)瀏覽器就不再緩存數據，只是瀏覽器在使用緩存數據時(shí)，需要先確認一下數據是否還跟服務(wù)器保持一致。
no-store：所有內容都不會(huì )被緩存，即不使用強制緩存，也不使用協(xié)商緩存
max-age：max-age=xxx (xxx is numeric)表示緩存內容將在xxx秒后失效
s-maxage（單位為s)：同max-age作用一樣，只在代理服務(wù)器中生效（比如CDN緩存）。比如當s-maxage=60時(shí)，在這60秒中，即使更新了CDN的內容，瀏覽器也不會(huì )進(jìn)行請求。max-age用于普通緩存，而s-maxage用于代理緩存。s-maxage的優(yōu)先級高于max-age。如果存在s-maxage，則會(huì )覆蓋掉max-age和Expires header。
max-stale：能容忍的最大過(guò)期時(shí)間。max-stale指令標示了客戶(hù)端愿意接收一個(gè)已經(jīng)過(guò)期了的響應。如果指定了max-stale的值，則最大容忍時(shí)間為對應的秒數。如果沒(méi)有指定，那么說(shuō)明瀏覽器愿意接收任何age的響應（age表示響應由源站生成或確認的時(shí)間與當前時(shí)間的差值）。
min-fresh：能夠容忍的最小新鮮度。min-fresh標示了客戶(hù)端不愿意接受新鮮度不多于當前的age加上min-fresh設定的時(shí)間之和的響應。
從圖中我們可以看到，我們可以將多個(gè)指令配合起來(lái)一起使用，達到多個(gè)目的。比如說(shuō)我們希望資源能被緩存下來(lái)，并且是客戶(hù)端和代理服務(wù)器都能緩存，還能設置緩存失效時(shí)間等等。
其實(shí)這兩者差別不大，區別就在于 Expires 是http1.0的產(chǎn)物，Cache-Control是http1.1的產(chǎn)物，兩者同時(shí)存在的話(huà)，Cache-Control優(yōu)先級高于Expires；在某些不支持HTTP1.1的環(huán)境下，Expires就會(huì )發(fā)揮用處。所以Expires其實(shí)是過(guò)時(shí)的產(chǎn)物，現階段它的存在只是一種兼容性的寫(xiě)法。強緩存判斷是否緩存的依據來(lái)自于是否超出某個(gè)時(shí)間或者某個(gè)時(shí)間段，而不關(guān)心服務(wù)器端文件是否已經(jīng)更新，這可能會(huì )導致加載文件不是服務(wù)器端最新的內容，那我們如何獲知服務(wù)器端內容是否已經(jīng)發(fā)生了更新呢？此時(shí)我們需要用到協(xié)商緩存策略。
協(xié)商緩存就是強制緩存失效后，瀏覽器攜帶緩存標識向服務(wù)器發(fā)起請求，由服務(wù)器根據緩存標識決定是否使用緩存的過(guò)程，主要有以下兩種情況：
協(xié)商緩存生效，返回304和Not Modified：
協(xié)商緩存失效，返回200和請求結果：
瀏覽器在第一次訪(fǎng)問(wèn)資源時(shí)，服務(wù)器返回資源的同時(shí)，在response header中添加 Last-Modified的header，值是這個(gè)資源在服務(wù)器上的最后修改時(shí)間，瀏覽器接收后緩存文件和header；
Last-Modified: Fri, 22 Jul 2016 01:47:00 GMT
瀏覽器下一次請求這個(gè)資源，瀏覽器檢測到有 Last-Modified這個(gè)header，于是添加If-Modified-Since這個(gè)header，值就是Last-Modified中的值；服務(wù)器再次收到這個(gè)資源請求，會(huì )根據 If-Modified-Since 中的值與服務(wù)器中這個(gè)資源的最后修改時(shí)間對比，如果沒(méi)有變化，返回304和空的響應體，直接從緩存讀取，如果If-Modified-Since的時(shí)間小于服務(wù)器中這個(gè)資源的最后修改時(shí)間，說(shuō)明文件有更新，于是返回新的資源文件和200。
如果本地打開(kāi)緩存文件，即使沒(méi)有對文件進(jìn)行修改，但還是會(huì )造成 Last-Modified 被修改，服務(wù)端不能命中緩存導致發(fā)送相同的資源
因為 Last-Modified 只能以秒計時(shí)，如果在不可感知的時(shí)間內修改完成文件，那么服務(wù)端會(huì )認為資源還是命中了，不會(huì )返回正確的資源
既然根據文件修改時(shí)間來(lái)決定是否緩存尚有不足，能否可以直接根據文件內容是否修改來(lái)決定緩存策略？所以在 HTTP / 1.1 出現了 ETag 和 If-None-Match
Etag是服務(wù)器響應請求時(shí)，返回當前資源文件的一個(gè)唯一標識(由服務(wù)器生成)，只要資源有變化，Etag就會(huì )重新生成。瀏覽器在下一次加載資源向服務(wù)器發(fā)送請求時(shí)，會(huì )將上一次返回的Etag值放到request header里的If-None-Match里，服務(wù)器只需要比較客戶(hù)端傳來(lái)的If-None-Match跟自己服務(wù)器上該資源的ETag是否一致，就能很好地判斷資源相對客戶(hù)端而言是否被修改過(guò)了。如果服務(wù)器發(fā)現ETag匹配不上，那么直接以常規GET 200回包形式將新的資源（當然也包括了新的ETag）發(fā)給客戶(hù)端；如果ETag是一致的，則直接返回304知會(huì )客戶(hù)端直接使用本地緩存即可。
3.兩者之間對比：
首先在精確度上，Etag要優(yōu)于Last-Modified。
Last-Modified的時(shí)間單位是秒，如果某個(gè)文件在1秒內改變了多次，那么他們的Last-Modified其實(shí)并沒(méi)有體現出來(lái)修改，但是Etag每次都會(huì )改變確保了精度；如果是負載均衡的服務(wù)器，各個(gè)服務(wù)器生成的Last-Modified也有可能不一致。
第二在性能上，Etag要遜于Last-Modified，畢竟Last-Modified只需要記錄時(shí)間，而Etag需要服務(wù)器通過(guò)算法來(lái)計算出一個(gè)hash值。
第三在優(yōu)先級上，服務(wù)器校驗優(yōu)先考慮Etag
強制緩存優(yōu)先于協(xié)商緩存進(jìn)行，若強制緩存(Expires和Cache-Control)生效則直接使用緩存，若不生效則進(jìn)行協(xié)商緩存(Last-Modified / If-Modified-Since和Etag / If-None-Match)，協(xié)商緩存由服務(wù)器決定是否使用緩存，若協(xié)商緩存失效，那么代表該請求的緩存失效，返回200，重新返回資源和緩存標識，再存入瀏覽器緩存中；生效則返回304，繼續使用緩存。具體流程圖如下：
看到這里，不知道你是否存在這樣一個(gè)疑問(wèn):如果什么緩存策略都沒(méi)設置，那么瀏覽器會(huì )怎么處理？
對于這種情況，瀏覽器會(huì )采用一個(gè)啟發(fā)式的算法，通常會(huì )取響應頭中的 Date 減去 Last-Modified 值的 10% 作為緩存時(shí)間。
Cache-Control: no-cache
對于頻繁變動(dòng)的資源，首先需要使用 Cache-Control:no-cache 使瀏覽器每次都請求服務(wù)器，然后配合 ETag 或者 Last-Modified 來(lái)驗證資源是否有效。這樣的做法雖然不能節省請求數量，但是能顯著(zhù)減少響應數據大小。
Cache-Control: max-age=31536000
通常在處理這類(lèi)資源時(shí)，給它們的 Cache-Control 配置一個(gè)很大的 max-age=31536000 (一年)，這樣瀏覽器之后請求相同的 URL 會(huì )命中強制緩存。而為了解決更新的問(wèn)題，就需要在文件名(或者路徑)中添加 hash， 版本號等動(dòng)態(tài)字符，之后更改動(dòng)態(tài)字符，從而達到更改引用 URL 的目的，讓之前的強制緩存失效 (其實(shí)并未立即失效，只是不再使用了而已)。在線(xiàn)提供的類(lèi)庫 (如 jquery-3.3.1.min.js, lodash.min.js 等) 均采用這個(gè)模式。
所謂用戶(hù)行為對瀏覽器緩存的影響，指的就是用戶(hù)在瀏覽器如何操作時(shí)，會(huì )觸發(fā)怎樣的緩存策略。主要有 3 種：
打開(kāi)網(wǎng)頁(yè)，地址欄輸入地址： 查找 disk cache 中是否有匹配。如有則使用；如沒(méi)有則發(fā)送網(wǎng)絡(luò )請求。
普通刷新 (F5)：因為 TAB 并沒(méi)有關(guān)閉，因此 memory cache 是可用的，會(huì )被優(yōu)先使用(如果匹配的話(huà))。其次才是 disk cache。
強制刷新 (Ctrl + F5)：瀏覽器不使用緩存，因此發(fā)送的請求頭部均帶有 Cache-control:no-cache(為了兼容，還帶了 Pragma:no-cache),服務(wù)器直接返回 200 和最新內容。
參考文章：
淺談web緩存
web緩存機制
徹底理解瀏覽器的緩存機制
前端面試之道
一文讀懂前端緩存
A Tale of Four Caches
HTTP/2 push is tougher than I thought
設計一個(gè)無(wú)懈可擊的瀏覽器緩存方案：關(guān)于思路，細節，ServiceWorker，以及HTTP/2
【End】
熱 文 推 薦
聯(lián)系客服
