摘要：從效率上來說，它是響應(yīng)速度最快的一種緩存。緩存緩存分為強緩存和協(xié)商緩存。是指在階段存在的緩存。服務(wù)器緩存，即內(nèi)容分發(fā)網(wǎng)絡(luò)指的是一組分布在各個地區(qū)的服務(wù)器。的核心點有兩個，一個是緩存，一個是回源。作用域和都遵循同源策略。

瀏覽器緩存機制有四個方面，它們按照獲取資源時請求的優(yōu)先級依次排列如下：

1.Memory Cache

2.Service Worker Cache

3.HTTP Cache

4.Push Cache

MemoryCache，是指存在內(nèi)存中的緩存。從優(yōu)先級上來說，它是瀏覽器最先嘗試去命中的一種緩存。從效率上來說，它是響應(yīng)速度最快的一種緩存。

不過當(dāng)頁面關(guān)閉時，內(nèi)存里的數(shù)據(jù)也就沒有了。

資源存不存內(nèi)存，瀏覽器秉承的是“節(jié)約原則”。我們發(fā)現(xiàn)，Base64 格式的圖片，幾乎永遠(yuǎn)可以被塞進 memory cache，這可以視作瀏覽器為節(jié)省渲染開銷的“自保行為”；此外，體積不大的 JS、CSS 文件，也有較大地被寫入內(nèi)存的幾率——相比之下，較大的 JS、CSS 文件就沒有這個待遇了，內(nèi)存資源是有限的，它們往往被直接甩進磁盤。

Service Worker 是一種獨立于主線程之外的 Javascript 線程。它可以幫我們實現(xiàn)離線緩存、消息推送和網(wǎng)絡(luò)代理等功能。

通常我們?nèi)绻褂?Service Worker 基本就是以下幾個步驟：

首先我們需要在頁面的 JavaScript 主線程中注冊 Service Worker。

注冊成功后后臺開始安裝步驟， 通常在安裝的過程中需要緩存一些靜態(tài)資源。

安裝成功后開始激活 Service Worker

激活成功后 Service Worker 可以控制頁面了（監(jiān)聽 fetch 和 message 事件），但是只針對在成功注冊了 Service Worker 后打開的頁面。

在頁面發(fā)起 http 請求時，service worker 可以通過 fetch 事件攔截請求，并且給出自己的響應(yīng)。

頁面和 serviceWorker 之間可以通過 posetMessage() 方法發(fā)送消息，發(fā)送的消息可以通過 message 事件接收到。

Service Worker 必須以 https 協(xié)議為前提。

HTTP 緩存分為強緩存和協(xié)商緩存。優(yōu)先級較高的是強緩存，在命中強緩存失敗的情況下，才會走協(xié)商緩存。

強緩存指的是向瀏覽器緩存查找該請求的結(jié)果，并根據(jù)該結(jié)果的緩存規(guī)則來決定是否使用該緩存結(jié)果的過程

強緩存是利用http響應(yīng)頭中的 Expires 和 Cache-Control 兩個字段來控制的。

實現(xiàn)強緩存，過去我們一直用 expires。

在服務(wù)器的響應(yīng)頭里，會將過期時間寫入 expires 字段：

那么，當(dāng)我們試圖再次向服務(wù)器請求資源時，瀏覽器就會先對比本地時間和 expires 的時間，如果本地時間小于 expires 設(shè)定的過期時間，就直接去緩存中取這個資源。

不過expires依賴于本地時間，如果服務(wù)端和客戶端的時間設(shè)置不同，那么expires 將無法達(dá)到我們的預(yù)期。

考慮到 expires 的局限性，HTTP1.1 新增了 Cache-Control 字段來完成 expires 的任務(wù)。當(dāng) Cache-Control 與 expires 同時出現(xiàn)時，我們以 Cache-Control 為準(zhǔn)。

Cache-Control 包含以下幾個值：

（1）max-age

cache-control: max-age=31536000

max-age 會等于一個時間長度（以秒為單位）。在本例中，max-age 是 31536000 秒，它意味著該資源在 31536000 秒以內(nèi)都是有效的，完美地規(guī)避了時間戳帶來的潛在問題。

在代理服務(wù)器中，我們使用 s-maxage 來執(zhí)行 max-age 的功能。

（2）public 與 private

如果我們?yōu)橘Y源設(shè)置了 public，那么它既可以被瀏覽器緩存，也可以被代理服務(wù)器緩存（也就是多個用戶可以共享這個緩存）；如果我們設(shè)置了 private，則該資源只能被瀏覽器緩存。

private 為默認(rèn)值。

但多數(shù)情況下，public 并不需要我們手動設(shè)置，因為設(shè)置了 max-age 就表示響應(yīng)是可以緩存的。

（3）no-store 與 no-cache

如果我們?yōu)橘Y源設(shè)置了 no-cache，瀏覽器會對響應(yīng)進行緩存，但是需要到服務(wù)器去確認(rèn)這個緩存是否能用。即走我們下文即將講解的協(xié)商緩存的路線。

如果設(shè)置了 no-store ，所有內(nèi)容都不會被緩存，即不使用強制緩存，也不使用協(xié)商緩存

協(xié)商緩存指的是強制緩存失效后，瀏覽器向服務(wù)器詢問緩存的相關(guān)信息，進而判斷是重新發(fā)起請求還是從本地拿緩存的過程。

如果服務(wù)端提示緩存資源未改動（Not Modified），資源會被重定向到瀏覽器緩存，這種情況下網(wǎng)絡(luò)請求對應(yīng)的狀態(tài)碼是 304（如下圖）。

同樣，協(xié)商緩存的標(biāo)識也是在響應(yīng)報文的HTTP頭中和請求結(jié)果一起返回給瀏覽器的，控制協(xié)商緩存的字段分別有：Last-Modified / If-Modified-Since和Etag / If-None-Match，其中Etag / If-None-Match的優(yōu)先級比Last-Modified / If-Modified-Since高。

如果我們啟用了協(xié)商緩存，Last-Modified 會在首次請求時隨著響應(yīng)頭返回：

Last-Modified: Fri, 27 Oct 2017 06:35:57 GMT

隨后我們每次請求時，會帶上一個叫 If-Modified-Since 的時間戳字段，它的值正是上一次 response 返回給它的 last-modified 值：

If-Modified-Since: Fri, 27 Oct 2017 06:35:57 GMT

服務(wù)器接收到這個時間戳后，會比對該時間戳和資源在服務(wù)器上的最后修改時間是否一致，從而判斷資源是否發(fā)生了變化。如果發(fā)生了變化，就會返回一個完整的響應(yīng)內(nèi)容，并在響應(yīng)頭中添加新的 Last-Modified 值；否則，返回如上圖的 304 響應(yīng)，響應(yīng)頭不會再添加 Last-Modified 字段。

Etag 是由服務(wù)器為每個資源生成的唯一的標(biāo)識字符串，這個標(biāo)識字符串是基于文件內(nèi)容編碼的，只要文件內(nèi)容不同，它們對應(yīng)的 Etag 就是不同的。

當(dāng)首次請求時，我們會在響應(yīng)頭里獲取到一個最初的標(biāo)識符字符串：

ETag: W/"2a3b-1602480f459"

那么下一次請求時，請求頭里就會帶上一個值相同的、名為 if-None-Match 的字符串供服務(wù)端比對:

If-None-Match: W/"2a3b-1602480f459"

不過 Etag 的生成過程需要服務(wù)器額外付出開銷，會影響服務(wù)端的性能。

根據(jù)上文所說的 HTTP 緩存知識點，我們在面對一個具體的緩存需求時，可以根據(jù)下圖的路線來決策：

當(dāng)我們的資源內(nèi)容不可復(fù)用時，直接為 Cache-Control 設(shè)置 no-store，拒絕一切形式的緩存；否則考慮是否每次都需要向服務(wù)器進行緩存有效確認(rèn)，如果需要，那么設(shè) Cache-Control 的值為 no-cache；否則考慮該資源是否可以被代理服務(wù)器緩存，根據(jù)其結(jié)果決定是設(shè)置為 private 還是 public；然后考慮該資源的過期時間，設(shè)置對應(yīng)的 max-age 和 s-maxage 值；最后，配置協(xié)商緩存需要用到的 Etag、Last-Modified 等參數(shù)。

Push Cache 是指 HTTP2 在 server push 階段存在的緩存。

CDN （Content Delivery Network，即內(nèi)容分發(fā)網(wǎng)絡(luò)）指的是一組分布在各個地區(qū)的服務(wù)器。這些服務(wù)器存儲著數(shù)據(jù)的副本，因此服務(wù)器可以根據(jù)哪些服務(wù)器與用戶距離最近，來滿足數(shù)據(jù)的請求。 CDN 提供快速服務(wù)，較少受高流量影響。

CDN 的核心點有兩個，一個是緩存，一個是回源。

“緩存”就是說我們把資源 copy 一份到 CDN 服務(wù)器上這個過程，“回源”就是說 CDN 發(fā)現(xiàn)自己沒有這個資源（一般是緩存的數(shù)據(jù)過期了），轉(zhuǎn)頭向根服務(wù)器（或者它的上層服務(wù)器）去要這個資源的過程。

CDN 往往被用來存放靜態(tài)資源，就是像 JS、CSS、圖片等不需要業(yè)務(wù)服務(wù)器進行計算即得的資源。

Web Storage 是 HTML5 專門為瀏覽器存儲而提供的數(shù)據(jù)存儲機制。存儲容量可以達(dá)到 5-10M 之間。它又分為 Local Storage 與 Session Storage。

兩者的區(qū)別在于生命周期與作用域的不同。

生命周期：存儲在Local Storage的數(shù)據(jù)是永遠(yuǎn)不會過期的，使其消失的唯一辦法是手動刪除；而 Session Storage 是臨時性的本地存儲，當(dāng)會話結(jié)束（頁面被關(guān)閉）時，存儲內(nèi)容也隨之被釋放。

作用域：Local Storage、Session Storage 和 Cookie 都遵循同源策略。但 Session Storage 特別的一點在于，即便是相同域名下的兩個頁面，只要它們不在同一個瀏覽器窗口中打開，那么它們的 Session Storage 內(nèi)容便無法共享。

（1）存儲數(shù)據(jù)

localStorage.setItem("user_name", "xiuyan")

sessionStorage.setItem("key", "value");

Web Storage只能存字符串。

（2）讀取數(shù)據(jù)

localStorage.getItem("user_name")

var data = sessionStorage.getItem("key");

（3）刪除某一鍵名對應(yīng)的數(shù)據(jù)

localStorage.removeItem("user_name")

sessionStorage.removeItem("key");

（4）清除所有數(shù)據(jù)

localStorage.clear()

sessionStorage.clear();

Local Storage 的特點之一是持久，有時我們更傾向于用它來存儲一些內(nèi)容穩(wěn)定的資源。比如圖片內(nèi)容豐富的電商網(wǎng)站會用它來存儲 Base64 格式的圖片字符串，有的網(wǎng)站還會用它存儲一些不經(jīng)常更新的 CSS、JS 等靜態(tài)資源。

Session Storage 更適合用來存儲生命周期和它同步的會話級別的信息。這些信息只適用于當(dāng)前會話，當(dāng)你開啟新的會話時，它也需要相應(yīng)的更新或釋放。比如微博的 Session Storage 就主要是存儲你本次會話的瀏覽足跡。

IndexDB 是一個運行在瀏覽器上的非關(guān)系型數(shù)據(jù)庫。

前端性能優(yōu)化原理與實踐

Service Worker 生命周期

Service Worker初體驗

徹底理解瀏覽器的緩存機制