瀏覽器緩存最佳實踐

最佳實踐

上來先說結論，緣由放在後面：

1. index.html 不作緩存，每次請求都獲取最新版本
2. 使用 webpack 等 build 後的其餘全部資源文件（包括 js、css 和圖片等），都作強緩存（一個月打底，能夠設置一年）

緣由

強緩存和協商緩存在社區已經被寫爛了，都知道是怎麼回事，這裏就不作詳細解釋了，這裏解釋下爲何說上面的是最佳實踐。

咱們知道協商緩存其實也向服務端發起了一個請求，只不過最後通過一系列驗證，結果就是不傳輸具體內容了，可是驗證的過程也給後端形成了一些開銷，因此咱們要儘可能減小這種開銷。

那麼把前端資源都用做強緩存就是最好的處理辦法了，可是又面臨一個問題『前端發版怎麼更新』

這時候咱們須要注意 build 後的前端資源，如今各個腳手架默認都會把文件名字生成一段 hash 值
xxx.6ae44c4e.js這種。原來我一直不明白這樣的意義在哪，如今明白了。

首先 index.html 不作緩存，因此當咱們發版之後瀏覽器會獲取到最新的 index.html 文件，因爲每次 build 以後生成的文件名字不一樣，index.html 引入的前端的資源就不一樣，舊的全部的資源文件包括 js、css 和圖片等）都不會影響新發版的內容。

這樣的話就作到了在不發版的狀況下，每次刷新基本就一個 index.html 的資源還有一些接口請求，其他的全都是強緩存資源。發版以後能夠立馬更新，不會形成資源混亂。如今掘金和 segmentfault 都是採起的這種策略。

實踐數據對比

和運維的同事商量了強緩存的優化，將 build 以後的 static 文件夾所有作了 add_header Cache-Control "max-age=30243600"，也就是強緩存 30 天的設置。

通過測試發現，由協商緩存到強緩存後，有以下變化：

類型	請求數	實際傳輸資源大小	傳輸完畢（Finish）	DOMContentLoaded	Load
協商緩存	631	168K	2.00s	447 ms	717 ms
強緩存	631	23K	1.43s	424 ms	704 ms

結果分析

首先，請求數量是同樣的，徹底 Load 的時候差很少，Finish 的時間提高了 25%，傳輸的資源大小減小了 80% 以上，同時因爲沒有和服務端去進行協商，至關於對服務端也作了優化。這些都是在協商緩存的基礎上作的優化對比，若是後端服務連協商緩存都沒上的話，真的應該優化一下了。