1.為什麼要使用瀏覽器快取

　　1.1減少網路請求

　　1.2加快瀏覽器響應時間

解釋：在使用者瀏覽網路的時候，同一個域名下的網頁大部分是有很多共同檔案的，比如第三方js檔案，css檔案，所以我們不可能當用戶每瀏覽一個網頁或者重新整理同一個網頁時，所有檔案都重新請求，那樣的頁面載入時間將會大大延長，使用者體驗也相當不好。

瀏覽器是如何快取的呢？

話不多說，先上一個思維導圖。 

2.快取位置

從快取位置上來說一共有四種，且各自有優先順序，查詢快取時會依次查詢，當都沒有找到時，才會去請求網路。

• Service Worker
• Memory Cache
• Disk Cache
• Push Cache

2.1Service Worker

　Service Worker 是執行在瀏覽器背後的獨立執行緒，一般可以用來實現快取功能。使用 　　Service Worker的話，傳輸協議必須為 HTTPS。因為 Service Worker 中涉及到請求攔截，所以必須使用 HTTPS 協議來保障安全。Service Worker 的快取與瀏覽器其他內建的快取機制不同，它可以讓我們自由控制快取哪些檔案、如何匹配快取、如何讀取快取，並且快取是持續性的。

至於Service Worker實現快取功能的步驟可以直接看圖：

步驟分為以下部分：

• register 這個是由 client 端發起，註冊一個 serviceWorker，這需要一個專門的 sw 處理檔案
• install 註冊成功後，此時 sw 中會觸發 install 事件， 需知 sw 中都是事件觸發的方式進行的邏輯呼叫
• activate 安裝後要等待啟用，也就是 activated 事件，只要 register 成功後就會觸發 install ，但不會立即觸發 activated，這個稍後再說
• idle 在 activated 之後就可以開始對 client 的請求進行攔截處理，sw 發起請求用的是 fetch api
• terminate 這一步是瀏覽器自身的判斷處理，當 sw 長時間不用之後，處於閒置狀態，瀏覽器會把該 sw 暫停，直到再次使

3.Memory Cache

Memory Cache 也就是記憶體中的快取，主要包含的是當前中頁面中已經抓取到的資源,例如頁面上已經下載的樣式、指令碼、圖片等。讀取記憶體中的資料肯定比磁碟快,記憶體快取雖然讀取高效，可是快取持續性很短，會隨著程序的釋放而釋放。 一旦我們關閉 Tab 頁面，記憶體中的快取也就被釋放了。

那麼既然記憶體快取這麼高效，我們是不是能讓資料都存放在記憶體中呢？
這是不可能的。計算機中的記憶體一定比硬碟容量小得多，作業系統需要精打細算記憶體的使用，所以能讓我們使用的記憶體必然不多。

當我們訪問過頁面以後，再次重新整理頁面，可以發現很多資料都來自於記憶體快取

需要注意的事情是，記憶體快取在快取資源時並不關心返回資源的HTTP快取頭Cache-Control是什麼值，同時資源的匹配也並非僅僅是對URL做匹配，還可能會對Content-Type，CORS等其他特徵做校驗

4.Disk Cache

Disk Cache 也就是儲存在硬碟中的快取，讀取速度慢點，但是什麼都能儲存到磁碟中，比之 Memory Cache 勝在容量和儲存時效性上。

在所有瀏覽器快取中，Disk Cache 覆蓋面基本是最大的。它會根據 HTTP Herder 中的欄位判斷哪些資源需要快取，哪些資源可以不請求直接使用，哪些資源已經過期需要重新請求。並且即使在跨站點的情況下，相同地址的資源一旦被硬碟快取下來，就不會再次去請求資料。絕大部分的快取都來自 Disk Cache，關於 HTTP 的協議頭中的快取欄位，我們會在下文進行詳細介紹。

5.Push Cache

Push Cache（推送快取）是 HTTP/2 中的內容，當以上三種快取都沒有命中時，它才會被使用。它只在會話（Session）中存在，一旦會話結束就被釋放，並且快取時間也很短暫，在Chrome瀏覽器中只有5分鐘左右，同時它也並非嚴格執行HTTP頭中的快取指令。

Push Cache 在國內能夠查到的資料很少，也是因為 HTTP/2 在國內不夠普及。這裡推薦閱讀Jake Archibald的 HTTP/2 push is tougher than I thought 這篇文章，文章中的幾個結論：

• 所有的資源都能被推送，並且能夠被快取,但是 Edge 和 Safari 瀏覽器支援相對比較差
• 可以推送 no-cache 和 no-store 的資源
• 一旦連線被關閉，Push Cache 就被釋放
• 多個頁面可以使用同一個HTTP/2的連線，也就可以使用同一個Push Cache。這主要還是依賴瀏覽器的實現而定，出於對效能的考慮，有的瀏覽器會對相同域名但不同的tab標籤使用同一個HTTP連線。
• Push Cache 中的快取只能被使用一次
• 瀏覽器可以拒絕接受已經存在的資源推送
• 你可以給其他域

  三、快取過程分析

  瀏覽器與伺服器通訊的方式為應答模式，即是：瀏覽器發起HTTP請求 – 伺服器響應該請求，那麼瀏覽器怎麼確定一個資源該不該快取，如何去快取呢？瀏覽器第一次向伺服器發起該請求後拿到請求結果後，將請求結果和快取標識存入瀏覽器快取，瀏覽器對於快取的處理是根據第一次請求資源時返回的響應頭來確定的。具體過程如下圖：

   

   

  第一次發起HTTP請求

  由上圖我們可以知道：

  • 瀏覽器每次發起請求，都會先在瀏覽器快取中查詢該請求的結果以及快取標識

  • 瀏覽器每次拿到返回的請求結果都會將該結果和快取標識存入瀏覽器快取中

  以上兩點結論就是瀏覽器快取機制的關鍵，它確保了每個請求的快取存入與讀取，只要我們再理解瀏覽器快取的使用規則，那麼所有的問題就迎刃而解了，本文也將圍繞著這點進行詳細分析。為了方便大家理解，這裡我們根據是否需要向伺服器重新發起HTTP請求將快取過程分為兩個部分，分別是強快取和協商快取。