一篇文章理解Web緩存

最近把前端緩存從新整理了一下，從總體的層面上把前端全部能用的緩存方案梳理了一遍。同時，對於http緩存，使用了表格的方案，使得原先晦澀難記的特性變得清晰明瞭。特記錄於此，如有什麼欠缺，也望不吝指出。

1. 前端緩存概述

前端緩存主要是分爲HTTP緩存和瀏覽器緩存。其中HTTP緩存是在HTTP請求傳輸時用到的緩存，主要在服務器代碼上設置；而瀏覽器緩存則主要由前端開發在前端js上進行設置。下面會分別具體描述。

2. 前端緩存分類

2.1 HTTP緩存

總體流程：HTTP緩存都是從 第二次請求開始的。
第一次請求資源時，服務器返回資源，並在respone header頭中回傳資源的緩存參數；第二次請求時，瀏覽器判斷這些請求參數，擊中強緩存就直接200，不然就把請求參數加到request header頭中傳給服務器，看是否擊中協商緩存，擊中則返回304，不然服務器會返回新的資源。

HTTP緩存分爲強緩存和協議緩存，它們的區別以下：

200 from disk or 200 from memory :
強緩存的200也有兩種狀況：200 from disk和200 from memory。如今我沒有找到明確的文檔來描述這種區別的發生條件。 知乎這個問題中提到了一些情景，能夠自行取用。

2.1.1 強緩存

2.1.2 協商緩存

協商緩存都是成對出現的。

2.1.3 最佳優化策略-消滅304

最佳優化策略：由於協商緩存自己也有http請求的損耗，因此最佳優化策略是要儘量的將靜態文件存儲爲較長的時間，多利用強緩存而不是協商緩存，即消滅304。

可是給文件設置一個很長的Cacha-Control也會帶來其餘的問題，最主要的問題是靜態內容更新時，用戶不能及時得到更新的內容。這時候就要使用hash的方法對文件進行命名，經過每次更新不一樣的靜態文件名來消除強緩存的影響。

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的內容能夠自動在請求的時候被傳遞給服務器。
LocalStorage的數據將一直保存在瀏覽器內，直到用戶清除瀏覽器緩存數據爲止。
SessionStorage的其餘屬性同LocalStorage，只不過它的生命週期同標籤頁的生命週期，當標籤頁被關閉時，SessionStorage也會被清除。

2.2.2 本地存儲大容量

WebSql和IndexDB主要用在前端有大容量存儲需求的頁面上，例如，在線編輯瀏覽器或者網頁郵箱。

2.2.3 應用緩存與PWA

應用緩存全稱爲Offline Web Application，它的緩存內容被存在瀏覽器的Application Cache中。它也是一個被W3C標準廢棄的功能，主要是經過manifest文件來標註要被緩存的靜態文件清單。可是在緩存靜態文件的同時，也會默認緩存html文件。這致使頁面的更新只能經過manifest文件中的版本號來決定。並且，即便咱們更新了version，用戶的第一次訪問仍是會訪問到老的頁面，只有下一次再訪問才能訪問到新的頁面。因此，應用緩存只適合那種常年不變化的靜態網站。如此的不方便，也是被廢棄的重要緣由。

PWA全稱是漸進式網絡應用，主要目標是實現web網站的APP式功能和展現。儘管PWA也有manifest文件，可是與應用緩存卻徹底不一樣。不一樣於manifest簡單的將文件經過是否緩存進行分類，PWA用manifest構建了本身的APP骨架。另外，PWA用Service Worker來控制緩存的使用。這一塊的內容較多，在這裏就不詳細展開了。

2.2.4 往返緩存

往返緩存又稱爲BFCache，是瀏覽器在前進後退按鈕上爲了提高歷史頁面的渲染速度的一種策略。BFCache會緩存全部的DOM結構，可是問題在於，一些頁面開始時進行的上報或者請求可能會被影響。這個問題如今主要會出如今微信h5的開發中。

去除BFCache有多種方法，但不是本文的重點，想了解的同窗能夠看《瀏覽器往返緩存（Back/Forward cache）問題的分析與解決》

總結

本文梳理了前端全部可能涉及的緩存，但願能從總體層面創建起系統的緩存知識體系。限於篇幅，每一部分的描述都比較簡略，僅起到拋磚引玉之用。若有錯誤，還望指出。