前端拾遺--http-前端緩存

時間 2020-03-22

標籤前端拾遺 http 緩存欄目 HTTP/TCP 简体版

原文原文鏈接

先簡單介紹一下現有的前端緩存技術方案，主要分爲http緩存和瀏覽器緩存。javascript

http緩存都是第二次請求時開始的，這也是個老生常談的話題了。無非也是那幾個http頭的問題：css

HTTP1.0的內容，服務器使用Expires頭來告訴Web客戶端它可使用當前副本，直到指定的時間爲止。前端

HTTP1.1引入了Cathe-Control，它使用max-age指定資源被緩存多久，主要是解決了Expires一個重大的缺陷，就是它設置的是一個固定的時間點，客戶端時間和服務端時間可能有偏差。java

Last-Modified是服務器告訴瀏覽器該資源的最後修改時間，If-Modified-Since是請求頭帶上的，上次服務器給本身的該資源的最後修改時間。而後服務器拿去對比。react

前面提到由文件的修改時間來判斷文件是否改動，仍是會帶來必定的偏差，好比註釋等可有可無的修改等。因此推出了新的方式。web

Etag是由服務端特定算法生成的該文件的惟一標識，而請求頭把返回的Etag值經過If-None-Match再帶給服務端，服務端經過比對從而決定是否響應新內容。這也是304緩存。

瀏覽器緩存

storage 簡單的緩存方式有cookie，localStorage和sessionStorage。這裏就不詳細介紹他們的區別了，這裏說下經過localStorage來緩存靜態資源的優化方案。面試
localStorage一般有5MB的存儲空間，咱們以微信文章頁爲例。算法

查看請求發現，基本沒有js和css的請求，由於它把所有的不須要改動的資源都放到了localStorage中：

因此微信的文章頁加載很是的快。

一般遵循如下基本步驟來使用 service workers：

service worker URL 經過 serviceWorkerContainer.register() 來獲取和註冊。
若是註冊成功，service worker 就在 ServiceWorkerGlobalScope 環境中運行；這是一個特殊類型的 woker 上下文運行環境，與主運行線程（執行腳本）相獨立，同時也沒有訪問 DOM 的能力。
service worker 如今能夠處理事件了。
受 service worker 控制的頁面打開後會嘗試去安裝 service worker。最早發送給 service worker 的事件是安裝事件(在這個事件裏能夠開始進行填充 IndexDB和緩存站點資源)。這個流程同原生 APP 或者 Firefox OS APP 是同樣的 — 讓全部資源可離線訪問。
當 oninstall 事件的處理程序執行完畢後，能夠認爲 service worker 安裝完成了。
下一步是激活。當 service worker 安裝完成後，會接收到一個激活事件(activate event)。 onactivate 主要用途是清理先前版本的service worker 腳本中使用的資源。
Service Worker 如今能夠控制頁面了，但僅是在 register() 成功後的打開的頁面。也就是說，頁面起始於有沒有 service worker ，且在頁面的接下來生命週期內維持這個狀態。因此，頁面不得不從新加載以讓 service worker 得到徹底的控制。

下圖展現了 service worker 全部支持的事件：