瀏覽器快取策略對於前端開發同學來說不陌生，大家都有一定的瞭解，但如果沒有系統的歸納總結，可能三言兩語很難說明白，甚至說錯，尤其在面試過程中感觸頗深，很多候選人對這類基礎知識竟然都是一知半解，說出幾個概念就沒了，所以重新歸納總結下，溫故而知新。
Web 快取介紹
Web 快取是指一個 Web 資源（如 html 頁面，圖片，js，資料等）存在於 Web 伺服器和客戶端（瀏覽器）之間的副本。 快取會根據進來的請求儲存輸出內容的副本；當下一個請求來到的時候，如果是相同的 URL，快取會根據快取機制決定是直接使用副本響應訪問請求，還是向源伺服器再次傳送請求。
Web 快取的好處
減少網路延遲，加快頁面開啟速度 減少網路頻寬消耗 降低伺服器壓力 ...
HTTP 的快取機制
簡化的流程如下
根據什麼規則快取
新鮮度（過期機制）：也就是快取副本有效期。一個快取副本必須滿足以下條件，瀏覽器會認為它是有效的，足夠新的：
含有完整的過期時間控制頭資訊（HTTP 協議報頭），並且仍在有效期內； 瀏覽器已經使用過這個快取副本，並且在一個會話中已經檢查過新鮮度；
校驗值（驗證機制）：伺服器返回資源的時候有時在控制頭資訊帶上這個資源的實體標籤 Etag（Entity Tag），它可以用來作為瀏覽器再次請求過程的校驗標識。如果發現校驗標識不匹配，說明資源已經被修改或過期，瀏覽器需求重新獲取資源內容。
HTTP 快取的兩個階段
瀏覽器快取一般分為兩類：強快取（也稱本地快取）和協商快取（也稱弱快取）。
本地快取階段
瀏覽器傳送請求前，會先去快取裡檢視是否命中強快取，如果命中，則直接從快取中讀取資源，不會傳送請求到伺服器。否則，進入下一步。
協商快取階段
當強快取沒有命中時，瀏覽器一定會向伺服器發起請求。伺服器會根據 Request Header 中的一些欄位來判斷是否命中協商快取。如果命中，伺服器會返回 304 響應，但是不會攜帶任何響應實體，只是告訴瀏覽器可以直接從瀏覽器快取中獲取這個資源。如果本地快取和協商快取都沒有命中，則從直接從伺服器載入資源。
啟用&關閉快取
按照本地快取階段和協商快取階段分類：
使用 HTML Meta 標籤 Web 開發者可以在 HTML 頁面的節點中加入標籤，如下：
上述程式碼的作用是告訴瀏覽器當前頁面不被快取，事實上這種禁用快取的形式用處很有限：
a. 僅有 IE 才能識別這段 meta 標籤含義，其它主流瀏覽器僅識別“Cache-Control: no-store”的 meta 標籤。
b. 在 IE 中識別到該 meta 標籤含義，並不一定會在請求欄位加上 Pragma，但的確會讓當前頁面每次都發新請求（僅限頁面，頁面上的資源則不受影響）。
使用快取有關的 HTTP 訊息報頭 這裡需要了解 HTTP 的基礎知識。一個 URI 的完整 HTTP 協議互動過程是由 HTTP 請求和 HTTP 響應組成的。有關 HTTP 詳細內容可參考《Hypertext Transfer Protocol — HTTP/1.1》、《HTTP 權威指南》等。
在 HTTP 請求和響應的訊息報頭中，常見的與快取有關的訊息報頭有：
上圖中只是常用的訊息報頭，下面來看下不同欄位之間的關係和區別：
Cache-Control 與 Expires
Cache-Control：HTTP1.1 提出的特性，為了彌補 Expires 缺陷加入的，提供了更精確細緻的快取功能。詳細瞭解詳細看幾個常見的指令：_ max-age：功能和 Expires 類似，但是後面跟一個以“秒”為單位的相對時間，來供瀏覽器計算過期時間。_ no-cache：提供了過期驗證機制。 (在 Chrome 的 devtools 中勾選 Disable cache 選項，傳送的請求會去掉 If-Modified-Since 這個 Header。同時設定 Cache-Control:no-cache Pragma:no-cache，每次請求均為 200)
no-store：表示當前請求資源禁用快取； public：表示快取的版本可以被代理伺服器或者其他中間伺服器識別； private：表示只有使用者自己的瀏覽器能夠進行快取，公共的代理伺服器不允許快取。
Expires：HTTP1.0 的特性，標識該資源過期的時間點，它是一個絕對值，格林威治時間（Greenwich Mean Time, GMT），即在這個時間點之後，快取的資源過期；優先順序：Cache-Control 優先順序高於 Expires，為了相容，通常兩個頭部同時設定；瀏覽器預設行為：其實就算 Response Header 中沒有設定 Cache-Control 和 Expires，瀏覽器仍然會快取某些資源，這是瀏覽器的預設行為，是為了提升效能進行的最佳化，每個瀏覽器的行為可能不一致，有些瀏覽器甚至沒有這樣的最佳化。
Last-Modified 與 ETag
Last-Modified(Response Header)與 If-Modified-Since(Request Header)是一對報文頭，屬於 http 1.0。
If-Modified-Since 是一個請求首部欄位，並且只能用在 GET 或者 HEAD 請求中。Last-Modified 是一個響應首部欄位，包含伺服器認定的資源作出修改的日期及時間。當帶著 If-Modified-Since 頭訪問伺服器請求資源時，伺服器會檢查 Last-Modified，如果 Last-Modified 的時間早於或等於 If-Modified-Since 則會返回一個不帶主體的 304 響應，否則將重新返回資源。
(注意：在 Chrome 的 devtools 中勾選 Disable cache 選項後，傳送的請求會去掉 If-Modified-Since 這個 Header。)
ETag 與 If-None-Match 是一對報文頭，屬於 http 1.1。
ETag 是一個響應首部欄位，它是根據實體內容生成的一段 hash 字串，標識資源的狀態，由服務端產生。If-None-Match 是一個條件式的請求首部。如果請求資源時在請求首部加上這個欄位，值為之前伺服器端返回的資源上的 ETag，則當且僅當伺服器上沒有任何資源的 ETag 屬性值與這個首部中列出的時候，伺服器才會返回帶有所請求資源實體的 200 響應，否則伺服器會返回不帶實體的 304 響應。
ETag 能解決什麼問題？
優先順序：ETag 優先順序比 Last-Modified 高，同時存在時會以 ETag 為準。
快取位置
瀏覽器可以在記憶體、硬碟中開闢一個空間用於儲存請求資源副本。我們經常除錯時在 DevTools Network 裡看到 Memory Cache（記憶體快取）和 Disk Cache（硬碟快取），指的就是快取所在的位置。請求一個資源時，會按照優先順序（Service Worker -> Memory Cache -> Disk Cache -> Push Cache）依次查詢快取，如果命中則使用快取，否則發起請求。這裡先介紹 Memory Cache 和 Disk Cache。
200 from memory cache
表示不訪問伺服器，直接從記憶體中讀取快取。因為快取的資源儲存在記憶體中，所以讀取速度較快，但是關閉程式後，快取資源也會隨之銷燬，一般來說，系統不會給記憶體分配較大的容量，因此記憶體快取一般用於儲存較小檔案。同時記憶體快取在有時效性要求的場景下也很有用（比如瀏覽器的隱私模式）。
200 from disk cache
表示不訪問伺服器，直接從硬碟中讀取快取。與記憶體相比，硬碟的讀取速度相對較慢，但硬碟快取持續的時間更長，關閉程式之後，快取的資源仍然存在。由於硬碟的容量較大，因此一般用於儲存大檔案。
下圖可清晰看出差別：
200 from prefetch cache
在 preload 或 prefetch 的資源載入時，兩者也是均儲存在 http cache，當資源載入完成後，如果資源是可以被快取的，那麼其被儲存在 http cache 中等待後續使用；如果資源不可被快取，那麼其在被使用前均儲存在 memory cache。
CDN Cache
以騰訊 CDN 為例：X-Cache-Lookup:Hit From MemCache 表示命中 CDN 節點的記憶體；X-Cache-Lookup:Hit From Disktank 表示命中 CDN 節點的磁碟；X-Cache-Lookup:Hit From Upstream 表示沒有命中 CDN。
整體流程
從上圖能感受到整個流程，比如常見兩種重新整理場景：
當 F5 重新整理網頁時，跳過強快取，但是會檢查協商快取； 當 Ctrl + F5 強制重新整理頁面時，直接從伺服器載入，跳過強快取和協商快取
其他 Web 快取策略
IndexDB
IndexedDB 就是瀏覽器提供的本地資料庫，能夠在客戶端儲存可觀數量的結構化資料，並且在這些資料上使用索引進行高效能檢索的 API。
非同步 API 方法呼叫完後會立即返回，而不會阻塞呼叫執行緒。要非同步訪問資料庫，要呼叫 window 物件 indexedDB 屬性的 open() 方法。該方法返回一個 IDBRequest 物件 (IDBOpenDBRequest)；非同步操作透過在 IDBRequest 物件上觸發事件來和呼叫程式進行通訊。
常用非同步 API 如下：
在 16 年曾基於 IndexDB 做過一整套快取策略，有不錯的最佳化效果：
Service Worker
SW 從 2014 年提出的草案到現在已經發展很成熟了，基於 SW 做離線快取，讓使用者能夠進行離線體驗，訊息推送體驗，離線快取能力涉及到 Cache 和 CacheStorage 的概念，篇幅有限，不展開了。
LocalStorage
localStorage 屬性允許你訪問一個 Document 源(origin)的物件 Storage 用於儲存當前源的資料，除非使用者人為清除(呼叫 localStorage api 或則清除瀏覽器資料)， 否則儲存在 localStorage 的資料將被長期保留。
SessionStorage
sessionStorage 屬性允許你訪問一個 session Storage 物件，用於儲存當前會話的資料，儲存在 sessionStorage 裡面的資料在頁面會話結束時會被清除。頁面會話在瀏覽器開啟期間一直保持，並且重新載入或恢復頁面仍會保持原來的頁面會話。
定義最優快取策略
使用一致的網址：如果您在不同的網址上提供相同的內容，將會多次獲取和儲存該內容。注意：URL 區分大小寫！ 確定中繼快取可以快取哪些資源：對所有使用者的響應完全相同的資源很適合由 CDN 或其他中繼快取進行快取； 確定每個資源的最優快取週期：不同的資源可能有不同的更新要求。審查並確定每個資源適合的 max-age； 確定網站的最佳快取層級：對 HTML 文件組合使用包含內容特徵碼的資源網址以及短時間或 no-cache 的生命週期，可以控制客戶端獲取更新的速度； 更新最小化：有些資源的更新比其他資源頻繁。如果資源的特定部分（例如 JS 函式或一組 CSS 樣式）會經常更新，應考慮將其程式碼作為單獨的檔案提供。這樣，每次獲取更新時，剩餘內容（例如不會頻繁更新的庫程式碼）可以從快取中獲取，確保下載的內容量最少； 確保伺服器配置或移除 ETag：因為 Etag 跟伺服器配置有關，每臺伺服器的 Etag 都是不同的； 善用 HTML5 的快取機制：合理設計啟用 LocalStorage、SessionStorage、IndexDB、SW 等儲存，會給頁面效能帶來明顯提升； 結合 Native 的強大儲存能力：善於利用客戶端能力，定製合適的快取機制，打造極致體驗。
結語
透過了解瀏覽器各種快取機制和儲存能力特點，結合業務制定合適的快取策略，善用快取是基本功，可以用於時常審查負責的業務，可能就會發現個別業務並沒有運用到位，共勉。
參考資料
https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9
https://www.digitalocean.com/community/tutorials/web-caching-basics-terminology-http-headers-and-caching-strategies
https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching?hl=en
https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Caching_FAQ
https://developer.mozilla.org/zh-CN/docs/Web/API/IndexedDB_API
https://juejin.im/post/5a673af06fb9a01c927ed880
https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching?hl=zh-cn