什么是 Web 緩存，這篇內(nèi)容讓你秒懂！
最近把前端緩存重新整理了一下，從整體的層面上把前端所有能用的緩存方案梳理了一遍。同時，對于http緩存，使用了表格的方案，使得原先晦澀難記的特性變得清晰明了。特記錄于此，若有什么欠缺，也望不吝指出。
1、前端緩存概述
前端緩存主要是分為HTTP緩存和瀏覽器緩存。其中HTTP緩存是在HTTP請求傳輸時用到的緩存，主要在服務器代碼上設置;而瀏覽器緩存則主要由前端開發(fā)在前端js上進行設置。下面會分別具體描述。
2、前端緩存分類
2.1 HTTP緩存
整體流程
HTTP緩存都是從第二次請求開始的。
第一次請求資源時，服務器返回資源，并在respone header頭中回傳資源的緩存參數(shù);第二次請求時，瀏覽器判斷這些請求參數(shù)，擊中強緩存就直接200，否則就把請求參數(shù)加到request header頭中傳給服務器，看是否擊中協(xié)商緩存，擊中則返回304，否則服務器會返回新的資源。
HTTP緩存分為強緩存和協(xié)議緩存，它們的區(qū)別如下：
200 from disk or 200 from memory
強緩存的200也有兩種情況：200 from disk和200 from memory?，F(xiàn)在我沒有找到明確的文檔來描述這種區(qū)別的發(fā)生條件。知乎這個問題中提到了一些情景，可以自行取用。
2.1.1 強緩存
2.1.2 協(xié)商緩存
協(xié)商緩存都是成對出現(xiàn)的。
2.1.3 最佳優(yōu)化策略——消滅304
最佳優(yōu)化策略：因為協(xié)商緩存本身也有http請求的損耗，所以最佳優(yōu)化策略是要盡可能的將靜態(tài)文件存儲為較長的時間，多利用強緩存而不是協(xié)商緩存，即消滅304。
但是給文件設置一個很長的Cacha-Control也會帶來其他的問題，最主要的問題是靜態(tài)內(nèi)容更新時，用戶不能及時獲得更新的內(nèi)容。這時候就要使用hash的方法對文件進行命名，通過每次更新不同的靜態(tài)文件名來消除強緩存的影響。
Hash命名：
- http://xxx.com/main.5eas34fa.js
- http://xxx.com/main.js?5eas34fa
- http://xxx.com/5eas34fa/main.js
2.2 瀏覽器緩存
2.2.1 本地存儲小容量
Cookie主要用于用戶信息的存儲，Cookie的內(nèi)容可以自動在請求的時候被傳遞給服務器。
LocalStorage的數(shù)據(jù)將一直保存在瀏覽器內(nèi)，直到用戶清除瀏覽器緩存數(shù)據(jù)為止。
SessionStorage的其他屬性同LocalStorage，只不過它的生命周期同標簽頁的生命周期，當標簽頁被關閉時，SessionStorage也會被清除。
2.2.2 本地存儲大容量
WebSql和IndexDB主要用在前端有大容量存儲需求的頁面上，例如，在線編輯瀏覽器或者網(wǎng)頁郵箱。
2.2.3 應用緩存與PWA
應用緩存全稱為Offline Web Application，它的緩存內(nèi)容被存在瀏覽器的Application Cache中。它也是一個被W3C標準廢棄的功能，主要是通過manifest文件來標注要被緩存的靜態(tài)文件清單。但是在緩存靜態(tài)文件的同時，也會默認緩存html文件。這導致頁面的更新只能通過manifest文件中的版本號來決定。而且，即使我們更新了version，用戶的第一次訪問還是會訪問到老的頁面，只有下一次再訪問才能訪問到新的頁面。所以，應用緩存只適合那種常年不變化的靜態(tài)網(wǎng)站。如此的不方便，也是被廢棄的重要原因。
PWA全稱是漸進式網(wǎng)絡應用，主要目標是實現(xiàn)web網(wǎng)站的APP式功能和展示。盡管PWA也有manifest文件，但是與應用緩存卻完全不同。不同于manifest簡單的將文件通過是否緩存進行分類，PWA用manifest構(gòu)建了自己的APP骨架。另外，PWA用Service Worker來控制緩存的使用。這一塊的內(nèi)容較多，在這里就不詳細展開了。
2.2.4 往返緩存
往返緩存又稱為BFCache，是瀏覽器在前進后退按鈕上為了提升歷史頁面的渲染速度的一種策略。BFCache會緩存所有的DOM結(jié)構(gòu)，但是問題在于，一些頁面開始時進行的上報或者請求可能會被影響。這個問題現(xiàn)在主要會出現(xiàn)在微信h5的開發(fā)中。
