前言
在訪問一個網頁時,客戶端會從服務器下載所需的資源。但是有些資源很少發生變動,例如 HTML、JS、CSS、圖片、字體文件等。如果每次加載頁面都從源服務器下載這些資源,不僅會增加獲取資源的時間,也會給服務器帶來一定壓力。因此,重用已獲取的資源十分重要。將請求的資源緩存下來,下次請求同一資源時,直接使用存儲的副本,而不會再去源服務器下載。這就是我們常說的緩存技術。
緩存的種類很多:瀏覽器緩存、網關緩存、CDN 緩存、代理服務器緩存等。這些緩存大致可以歸爲兩類:共享緩存和私有緩存。共享緩存能夠被多個用戶使用,而私有緩存只能用於單個用戶。瀏覽器緩存只存在於每個單獨的客戶端,因此它是私有緩存。
本文主要介紹私有(瀏覽器)緩存。你將學習:
- 瀏覽器緩存的分類
- 如何啓用和禁止緩存
- 緩存存儲的位置
- 如何設置緩存的過期時間
- 緩存過期之後會發生什麼
- 如何爲自己的應用制定合適的緩存策略
-
調試
- 如何判斷網站是否啓用了緩存
- 如何禁用瀏覽器緩存
緩存存儲
啓用緩存
Cache-Control
瀏覽器會根據 HTTP Response Headers 中的一些字段來決定是否要緩存該資源。通過設置 Response Headers 中的 Cache-Control
和 Expires
可以啓用緩存,這樣資源就會被緩存到客戶端。
Cache-Control
可以設置 private
、public
、max-age
、 no-cache
來啓用緩存。
Cache-Control: private/public
Cache-Control: max-age=300
Cache-Control: no-cache
-
private
:表示該資源只能被瀏覽器緩存。 -
public
:表示該資源既能被瀏覽器緩存,也能被任何中間人(比如代理服務器、CDN 等)緩存。 -
max-age
:表示該資源能夠被緩存的最大時間。如果設置max-age=0
,該資源仍然會被瀏覽器緩存,只不過立刻就過期了。 -
no-cache
:該資源會被緩存,但是立刻就過期了,因此需要先和服務器確認資源是否發生變化,只有當資源沒有變化時,該緩存纔會被使用,否則需要從服務器下載。相當於max-age=0
。
Expires
Expires
標識了緩存的具體過期時間,來控制資源何時過期。通過設置 Expires 可以啓用緩存。不過需要注意 Expires 的值是格林威治時間(Greenwich Mean Time, GMT),不是本地時間。
Expires: Fri, 08 Mar 2029 08:05:59 GMT
Expires: 0 // Expires: 0 仍然會啓用緩存,只不過緩存立刻過期。
優先級
既然 Cache-Control 和 Expires 都能夠啓用緩存,那麼問題來了,如果同時設置 Cache-Control: max-age=600
和 Expires: 0
,那麼瀏覽器應該如何緩存該資源呢?答案是隻有 Cache-Control: max-age=600
生效。因爲 Cache-Control 的優先級高於 Expires,如果同時設置了 Cache-Control 和 Expires,以 Cache-Control 爲準。
瀏覽器的默認行爲
設置 Cache-Control 之後,可以看到瀏覽器確實啓用了緩存(from disk cache)。如下所示:
Cache-Control:max-age=604800, must-revalidate, public
但是我發現,即使 Response Header 中沒有設置 Cache-Control 和 Expires,瀏覽器仍然會緩存某些資源。這是爲什麼呢?
原來當 Response Header 中有 Last-Modified 但是沒有 Cache-Control 和 Expires 時,瀏覽器會用一套自己的算法來決定這個資源會被緩存多長時間。這是瀏覽器爲了提升性能進行的優化,每個瀏覽器的行爲可能不一致,有些瀏覽器上甚至沒有這樣的優化。因此,如果要啓用緩存,還是應該自己設置合適的 Cache-Control 和 Expires,不要依賴瀏覽器自身的緩存算法。當然,如果在調試時發現本應該更新的文件沒有更新,也別忘了看看是否被瀏覽器緩存了。
禁止緩存
給 Cache-Control
設置 no-store
會禁止瀏覽器和中間人緩存該資源。在處理包含個人隱私數據或銀行業務數據的資源時很有用。
Cache-Control: no-store
緩存目標對象
一般來說,瀏覽器緩存只能存儲 GET
響應,例如 HTML、JS、CSS、圖片等靜態資源。因爲這些資源不經常發生變化,所以緩存可以幫助提升獲取資源的速度。但是像一些 POST/DELETE 請求,這些請求基本上每一次都不一樣,因此也沒有什麼緩存的價值。
緩存位置
瀏覽器可以在內存、硬盤中開闢一個空間用以保存請求資源的副本。我們經常在 Dev Tools 裏面看到 Memory Cache(內存緩存)和 Disk Cache(硬盤緩存),指的就是緩存所在的位置。請求一個資源時,會按照優先級(Service Worker -> Memory Cache -> Disk Cache -> Push Cache)依次查找緩存,如果命中則使用緩存,否則發起網絡請求。這裏只介紹常用的 Memory Cache 和 Disk Cache。
200 from Memory Cache
表示不訪問服務器,直接從內存中讀取緩存。因爲緩存的資源保存在內存中,所以讀取速度較快,但是關閉進程之後,緩存的資源也會隨之銷燬。一般來說,系統不會給內存分配較大的容量,因此內存緩存一般用於存儲小文件。同時,內存緩存在有時效性要求的場景下也很有用(比如瀏覽器的隱私模式)。
200 from Disk Cache
表示不訪問服務器,直接從硬盤中讀取緩存。與內存相比,硬盤的讀取速度較慢,但是硬盤緩存持續的時間更長,關閉進程之後,緩存的資源仍然存在。由於硬盤的容量較大,因此一般用於存儲大文件。
總的來說就是:
內存緩存:讀取快、持續時間短、容量小
硬盤緩存:讀取慢、持續時間長、容量大
緩存分類
瀏覽器緩存一般分爲兩類:強緩存(也稱本地緩存)和協商緩存(也稱弱緩存)。判定過程如下:
- 瀏覽器發送請求前,會先去緩存裏面查看是否命中強緩存,如果命中,則直接從緩存中讀取資源,不會發送請求到服務器。否則,進入下一步。
- 當強緩存沒有命中時,瀏覽器一定會向服務器發起請求。服務器會根據 Request Header 中的一些字段來判斷是否命中協商緩存。如果命中,服務器會返回響應,但是不會攜帶任何響應實體,只是告訴瀏覽器可以直接從緩存中獲取這個資源。否則,進入下一步。
- 如果前兩步都沒有命中,則直接從服務器加載資源。
強緩存和協商緩存的共同點在於,如果命中,都是從客戶端緩存中加載資源,而不是從服務器加載資源。而不同點在於,強緩存不發送請求到服務器,而協商緩存會發送請求到服務器以驗證資源是否過期。普通刷新會啓用協商緩存,忽略強緩存。只有在地址欄或收藏夾輸入網址、通過鏈接引用資源等情況下,瀏覽器纔會啓用強緩存。
緩存過期策略
當緩存過期之後,瀏覽器會向服務器發起 HTTP 請求,以確定資源是否發生了變化。如果資源未改變,那麼瀏覽器會繼續使用本地的緩存資源;如果該資源已經發生變化了,那麼瀏覽器會刪除舊的緩存資源,並將新的資源緩存到本地。
過期時間
Http Response Header 裏面的 Cache-Control: max-age=xxx
和 Expires
都可以設置緩存的過期時間,但是它們有一些區別:
Expires
:標識該資源過期的時間點,它是一個絕對值,即在這個時間點之後,緩存的資源過期。max-age
:標識該資源能夠被緩存的最大的時間。它是一個相對值,相對於第一次請求該文檔時服務器記錄的「請求發起時間」。
雖然 Cache-Control 是 HTTP 1.1 提出來的新特性,但並不是說 max-age 優於 Expires。它們都有各自的使用場景,我們應該根據業務需求去決定使用哪一個。比如當某個資源需要在特定的時間點過期時應該使用 Expires 。如果只是爲了開啓緩存,使用 max-age 可能會更好些,因爲 Cache-Control 的優先級高於 Expires。
針對應用中幾乎不會改變的文件,通常可以設置一個較長的過期時間,以保證緩存的有效。例如圖片、CSS、JS 等靜態資源。
緩存驗證
上一小節已經提到,當瀏覽器請求一個資源時,如果發現緩存中有該資源,但是已經過期了,那麼瀏覽器就會向服務器發起 HTTP 請求,以驗證緩存的資源是否發生變化。
緩存驗證時機
什麼時候會進行緩存驗證?
- 刷新頁面。一般來說,爲了確保用戶獲取到最新的數據,在刷新頁面時大部分瀏覽器都不會再使用緩存中的數據,而是發起一個請求去服務器驗證。
- Response Header 中設置了 Cache-control: must-revalidate。當緩存的資源過期之後,必須到源服務器去驗證,只有確認該資源沒有過期,才能繼續使用緩存。
緩存驗證器
服務器是怎麼判斷資源改變與否的呢?服務端在返回響應內容的同時,還會在 Response Header 中設置一些驗證標識,當緩存的資源過期之後,瀏覽器就會攜帶驗證標識向服務器發起請求,服務器通過對比這些標識,就能知道緩存的資源是否發生了改變。
Header 中的驗證標識字段主要有兩組:Etag
和 If-None-Match
、Last-Modified
和 If-Modified-Since
。其中,形如 If-xxx
這樣的請求首部字段,可以稱之爲條件請求。比如只在滿足某個條件的情況下返回或上傳文件,這樣可以節省帶寬。
Last-Modified
Last-Modified 就是一個驗證器。服務器在將資源返回給客戶端的同時,會將資源的最後修改時間 Last-Modified 加在 Response Header 中一起返回。瀏覽器會爲資源標記上該信息,當緩存過期之後,瀏覽器會把該信息設置到 Request Header 中的 If-Modified-Since
中向服務器發起請求。
如果 If-Modified-Since 中的值和服務器上該資源最終的修改時間一致,就說明該資源沒有被修改過,服務器會直接返回 304 狀態碼,無響應實體,這樣就可以節省傳輸的數據量。如果不一致,服務器會返回 200 狀態碼,同時和第一次 HTTP 請求一樣,返回響應實體和驗證器。
Last-Modified:Fri, 04 Jan 2019 14:00:21 GMT
Etag
服務器會通過某種算法,爲資源計算出一個唯一標識符,在把響應返回給客戶端的時候,會在 Response Header 中加上 Etag: 唯一標識符
一起返回給客戶端。
Etag:"952d03d8561454120b550f0a5679a172c4822ce8"
客戶端會將 Etag 保存下來,後續請求時會將 Etag 作爲 Request Header 中 If-None-Match
的值發給服務器。通過比對客戶端發過來的 Etag 和服務器上保存的 Etag 是否一致,就能夠知道資源是否發生了變化。如果資源沒有發生變化,返回 304,客戶端繼續使用緩存。如果資源已經修改,則返回 200。
制定緩存策略
緩存真的可以說讓我們又愛又恨。在開發時,我們經常遇到這樣的問題:明明已經修改了這個文件,爲什麼沒有生效?好吧,文件被緩存了。。。但是在上線時,我們又希望文件儘可能地被瀏覽器緩存,來提高性能。因此爲自己的應用制定合適的緩存策略非常重要。
爲靜態資源設置較長緩存時間。
有些資源很長時間都不會改變,比如一些三方庫,圖片,字體文件等。可以爲它們設置一個很長的過期時間,例如設定「一年」。
通過給文件名的唯一標識來確保文件修改生效。
有些時候爲了解決 bug,我們可能會修改一些文件,比如應用的 CSS、JS 等。如果這些文件已經被緩存,那麼除非用戶強制刷新頁面,否則用戶只有在緩存過期之後纔有可能獲取新的文件。如何讓瀏覽器不使用緩存,而是重新下載新的文件呢?有一個辦法就是給文件名加上唯一標識,比如 Hash 或版本信息。當文件修改之後,這個唯一標識也會隨之改變。瀏覽器發現文件改變之後,就不會使用緩存了。
明確是否有資源不能被緩存。
比如一些敏感數據,如果不應該被瀏覽器緩存,需要在 Response Header 中設置 Cache-Control: no-store。
調試
如何知道請求的資源是否被緩存了?打開 Chrome 的開發者工具,我們可以看到 Size 這一欄下面,如果顯示文件真實的大小,則說明該文件未被緩存。如果顯示 from xxx cache,則說明該請求使用的是已被緩存的文件。如下:
調試時,如果想禁用瀏覽器緩存,可以在開發者工具上勾選 Disabel cache。
最後
最後,大家可以通過下面這張圖再回顧一下我們剛剛講過的內容。