一、前端緩存概述
- 前端緩存主要是分爲HTTP緩存和瀏覽器緩存。
- HTTP緩存是在HTTP請求傳輸時用到的緩存，主要在服務器代碼上設置；
- 而瀏覽器緩存主要由前端開發在前端js上進行設置。
二、分類
1. HTTP緩存
HTTP緩存都是從第二次請求開始的。第一次請求資源時，服務器返回資源，並在respone header頭中回傳資源的緩存參數；第二次請求時， 瀏覽器判斷這些請求參數，擊中強緩存就直接200，否則就把請求參數加到request header頭中傳給服務器，看是否擊中協商緩存，擊中返回304，否則服務器會返回新的資源。
- 1.1 強緩存
| 可選值 | 優先級 | 優缺點 | |
|---|---|---|---|
| Pragma | no-cache：不能直接使用緩存，開始服務器新鮮度判定 | 中 | 已被廢棄 |
| Cache-Control | max-age：xx秒：相對時間，強緩存必備 no-cache：不直接使用緩存，開始服務器新鮮度判定 no-store：每次都下載最新資源 public/private: 是否只能被單個用戶保存 | 高 | 無 |
| Expires | GMT時間 | 低 | 服務器和本地的時間不一定統一 |
- 1.2 協商緩存
協商緩存都是成對出現的
| 可選值 | 優先級 | 優缺點 | |
|---|---|---|---|
| Last-Modify/if-Modify-Since | GMT時間 | 依次比較，排序靠後 | 1.修改並不意味着改變 2.秒級判斷 |
| ETag/if-None-Match | 校驗值 | 依次比較，先比較 | 使用系統默認的hash算法，在分佈式部署中會導致不同服務器的ETag值不一致 |
強緩存和協商緩存區別：
| 強緩存 | 協商緩存 | |
|---|---|---|
| HTTP狀態碼 | 200 | 304 |
| 緩存位置 | 本地瀏覽器 | 本地瀏覽器 |
| 誰來決定 | 本地瀏覽器 | 服務器 |
| 是否有效 | F5刷新無效，Ctrl+F5刷新無效 | F5刷新有效，Ctrl+F5刷新無效 |
200 from disk or 200 from memory : 強緩存的200也有兩種情況：200 from disk和200 from memory。現在我沒有找到明確的文檔來描述這種區別的發生條件。知乎這個問題中提到了一些情景，可以自行取用。
- 1.3 最佳優化策略 消滅304
最佳優化策略：因爲協商緩存本身也有http請求的損耗，所以最佳優化策略是要儘可能的將靜態文件存儲爲較長的時間，多利用強緩存存儲，而不是協商緩存，即消滅304。
但是給文件設置一個很長的Cacha-Control也會帶來其他的問題，最主要的問題是靜態內容更新時，用戶不能及時獲得更新的內容。這時候就要使用hash的方法對文件進行命名，通過每次更新不同的靜態文件名來消除強緩存的影響。
Hash命名：http://xxx.com/main.5eas34fa.js http://xxx.com/main.js?5eas34fahttp://xxx.com/5eas34fa/main.js
2. 瀏覽器緩存
-
2.1 本地存儲
webStorage- localStorage
- sessionStorage
Cookie
Cookie主要用於用戶信息的存儲，Cookie的內容可以自動在請求的時候被傳遞給服務器。 LocalStorage的數據將一直保存在瀏覽器內，直到用戶清除瀏覽器緩存數據爲止。 SessionStorage的其他屬性同LocalStorage，只不過它的生命週期同標籤頁的生命週期，當標籤頁被關閉時，SessionStorage也會被清除。
| 容量 | 作用 | |
|---|---|---|
| Cookie | 4KB | 請求時傳遞 |
| LocalStorage | 5MB | 永久存儲 |
| SessionStorage | 5MB | 同標籤頁生命週期，不同頁面間交換數據 |
WebSql
IndexDB
| 介紹 | 容量 | 狀態 | |
|---|---|---|---|
| WebSql | 關係型數據庫 | 不知道，應該是50M左右 | 被W3C標準廢棄 |
| IndexDB | 非關係型數據庫 | 50MB | 正常使用 |
應用緩存Application Cache
PWA
應用緩存與PWA
應用緩存全稱爲Offline Web Application，它的緩存內容被存在瀏覽器的Application Cache中。它也是一個被W3C標準廢棄的功能，主要是通過manifest文件來標註要被緩存的靜態文件清單。但是在緩存靜態文件的同時，也會默認緩存html文件。這導致頁面的更新只能通過manifest文件中的版本號來決定。而且，即使我們更新了version，用戶的第一次訪問還是會訪問到老的頁面，只有下一次再訪問才能訪問到新的頁面。所以，應用緩存只適合那種常年不變化的靜態網站。如此的不方便，也是被廢棄的重要原因。
PWA全稱是漸進式網絡應用，主要目標是實現web網站的APP式功能和展示。儘管PWA也有manifest文件，但是與應用緩存卻完全不同。不同於manifest簡單的將文件通過是否緩存進行分類，PWA用manifest構建了自己的APP骨架。另外，PWA用Service Worker來控制緩存的使用。這一塊的內容較多，在這裏就不詳細展開了。
| 類別 | 主要部分 | 作用 | 狀態 |
|---|---|---|---|
| 應用緩存 | Manifest | 離線緩存 | 被W3C標準廢棄 |
| PWA | Manifest,SW.js | APP式應用 | 正常使用，但瀏覽器兼容性不好 |
- 2.2 默認緩存
往返緩存又稱爲BFCache，是瀏覽器在前進後退按鈕上爲了提升歷史頁面的渲染速度的一種策略。BFCache會緩存所有的DOM結構，但是問題在於，一些頁面開始時進行的上報或者請求可能會被影響。這個問題現在主要會出現在微信h5的開發中。
去除BFCache有多種方法，但不是本文的重點，想了解的同學可以看《瀏覽器往返緩存（Back/Forward cache）問題的分析與解決》
總結
本文梳理了幾乎前端所有可能涉及到的緩存，從整體層面建立起系統的緩存知識體系。每一部分，描述比較簡略，僅起到拋磚引玉.。