摘要：瀏覽器緩存作為性能優(yōu)化的重要一環(huán)，對于前端而言，重要性不言而喻。根據(jù)瀏覽器發(fā)送的修改時間和服務(wù)端的修改時間進行比對，一致的話代表資源沒有改變，服務(wù)端返回正文為空的響應，讓瀏覽器中緩存中讀取資源，這就大大減小了請求的消耗。

瀏覽器緩存作為性能優(yōu)化的重要一環(huán)，對于前端而言，重要性不言而喻。以前總是一知半解的，所以這次好好整理總結(jié)了一下。

首先我們來總體感知一下它的匹配流程，如下：

瀏覽器發(fā)送請求前，根據(jù)請求頭的expires和cache-control判斷是否命中（包括是否過期）強緩存策略，如果命中，直接從緩存獲取資源，并不會發(fā)送請求。如果沒有命中，則進入下一步。

沒有命中強緩存規(guī)則，瀏覽器會發(fā)送請求，根據(jù)請求頭的last-modified和etag判斷是否命中協(xié)商緩存，如果命中，直接從緩存獲取資源。如果沒有命中，則進入下一步。

如果前兩步都沒有命中，則直接從服務(wù)端獲取資源。

強緩存：不會向服務(wù)器發(fā)送請求，直接從緩存中讀取資源。

強制緩存就是向瀏覽器緩存查找該請求結(jié)果，并根據(jù)該結(jié)果的緩存規(guī)則來決定是否使用該緩存結(jié)果的過程，強制緩存的情況主要有三種(暫不分析協(xié)商緩存過程)，如下：

第一次請求，不存在緩存結(jié)果和緩存標識，直接向服務(wù)器發(fā)送請求

存在緩存標識和緩存結(jié)果，但是已經(jīng)失效，強制緩存是啊比，則使用協(xié)商緩存（暫不分析）

存在該緩存結(jié)果和緩存標識，且該結(jié)果尚未失效，強制緩存生效，直接返回該結(jié)果

那么強制緩存的緩存規(guī)則是什么？
當瀏覽器向服務(wù)器發(fā)起請求時，服務(wù)器會將緩存規(guī)則放入HTTP響應報文的HTTP頭中和請求結(jié)果一起返回給瀏覽器，控制強制緩存的字段分別是Expires和Cache-Control，其中Cache-Control優(yōu)先級比Expires高。

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

Expires 是 HTTP/1 的產(chǎn)物，受限于本地時間，如果修改了本地時間，可能會造成緩存失效。

在HTTP/1.1中，Cache-Control是最重要的規(guī)則，主要用于控制網(wǎng)頁緩存，主要取值為：

public：所有內(nèi)容都將被緩存（客戶端和代理服務(wù)器都可緩存）

private：所有內(nèi)容只有客戶端可以緩存，Cache-Control的默認取值

no-cache：客戶端緩存內(nèi)容，但是是否使用緩存則需要經(jīng)過協(xié)商緩存來驗證決定

no-store：所有內(nèi)容都不會被緩存，即不使用強制緩存，也不使用協(xié)商緩存

max-age=xxx (xxx is numeric)：緩存內(nèi)容將在xxx秒后失效

需要注意的是，no-cache這個名字有一點誤導。設(shè)置了no-cache之后，并不是說瀏覽器就不再緩存數(shù)據(jù)，只是瀏覽器在使用緩存數(shù)據(jù)時，需要先確認一下數(shù)據(jù)是否還跟服務(wù)器保持一致，也就是協(xié)商緩存。而no-store才表示不會被緩存，即不使用強制緩存，也不使用協(xié)商緩存

強緩存需要服務(wù)端設(shè)置expires和cache-control。
nginx代碼參考，設(shè)置了一年的緩存時間：

location ~ .*.(ico|svg|ttf|eot|woff)(.*) {
  proxy_cache               pnc;
  proxy_cache_valid         200 304 1y;
  proxy_cache_valid         any 1m;
  proxy_cache_lock          on;
  proxy_cache_lock_timeout  5s;
  proxy_cache_use_stale     updating error timeout invalid_header http_500 http_502;
  expires                   1y;
}

瀏覽器的緩存存放在哪里，如何在瀏覽器中判斷強制緩存是否生效？這就是下面我們要講到的from disk cache和from memory cache。

細心地同學在開發(fā)的時候應該注意到了Chrome的網(wǎng)絡(luò)請求的Size會出現(xiàn)三種情況from disk cache(磁盤緩存)、from memory cache(內(nèi)存緩存)、以及資源大小數(shù)值。

瀏覽器讀取緩存的順序為memory –> disk。
以訪問https://github.com/xiangxingchen/blog為例
我們第一次訪問時https://github.com/xiangxingchen/blog

關(guān)閉標簽頁，再此打開https://github.com/xiangxingchen/blog時

F5刷新時

簡單的對比一下

協(xié)商緩存就是強制緩存失效后，瀏覽器攜帶緩存標識向服務(wù)器發(fā)起請求，由服務(wù)器根據(jù)緩存標識決定是否使用緩存的過程，主要有以下兩種情況：

協(xié)商緩存生效，返回304和Not Modified

協(xié)商緩存失效，返回200和請求結(jié)果

瀏覽器首先發(fā)送一個請求，讓服務(wù)端在response header中返回請求的資源上次更新時間，就是last-modified，瀏覽器會緩存下這個時間。

然后瀏覽器再下次請求中，request header中帶上if-modified-since:[保存的last-modified的值]。根據(jù)瀏覽器發(fā)送的修改時間和服務(wù)端的修改時間進行比對，一致的話代表資源沒有改變，服務(wù)端返回正文為空的響應，讓瀏覽器中緩存中讀取資源，這就大大減小了請求的消耗。

由于last-modified依賴的是保存的絕對時間，還是會出現(xiàn)誤差的情況：

保存的時間是以秒為單位的，1秒內(nèi)多次修改是無法捕捉到的；

各機器讀取到的時間不一致，就有出現(xiàn)誤差的可能性。為了改善這個問題，提出了使用etag。

etag是http協(xié)議提供的若干機制中的一種Web緩存驗證機制，并且允許客戶端進行緩存協(xié)商。生成etag常用的方法包括對資源內(nèi)容使用抗碰撞散列函數(shù)，使用最近修改的時間戳的哈希值，甚至只是一個版本號。 和last-modified一樣.

瀏覽器會先發(fā)送一個請求得到etag的值，然后再下一次請求在request header中帶上if-none-match:[保存的etag的值]。

通過發(fā)送的etag的值和服務(wù)端重新生成的etag的值進行比對，如果一致代表資源沒有改變，服務(wù)端返回正文為空的響應，告訴瀏覽器從緩存中讀取資源。

etag能夠解決last-modified的一些缺點，但是etag每次服務(wù)端生成都需要進行讀寫操作，而last-modified只需要讀取操作，從這方面來看，etag的消耗是更大的。

二者對比

精確度上：Etag要優(yōu)于Last-Modified。

優(yōu)先級上：服務(wù)器校驗優(yōu)先考慮Etag。

性能上：Etag要遜于Last-Modified

打開網(wǎng)頁，地址欄輸入地址： 查找 disk cache 中是否有匹配。如有則使用；如沒有則發(fā)送網(wǎng)絡(luò)請求。

普通刷新 (F5)：因為 TAB 并沒有關(guān)閉，因此 memory cache 是可用的，會被優(yōu)先使用(如果匹配的話)。其次才是 disk cache。

強制刷新 (Ctrl + F5)：瀏覽器不使用緩存，因此發(fā)送的請求頭部均帶有 Cache-control:no-cache(為了兼容，還帶了 Pragma:no-cache),服務(wù)器直接返回 200 和最新內(nèi)容。

如果有錯誤或者不嚴謹?shù)牡胤?，請?wù)必給予指正，十分感謝。如果喜歡或者有所啟發(fā)，歡迎star對作者也是一種鼓勵。