摘要：已經(jīng)得到越來越多的瀏覽器的支持，包括蘋果騰訊的內(nèi)核。蘋果從開始，已經(jīng)開始支持了。針對各種應(yīng)用場景的多種緩存策略。在無網(wǎng)絡(luò)環(huán)境的情況，也可以做到離線緩存的效果，極大地提升頁面的用戶體驗。

什么是workbox，workbox有什么用途，為什么要使用它？在介紹workbox之前，我們來先大致了解一下service worker，有助于我們后面更好地去理解workbox。

service worker是在瀏覽器后臺獨立于網(wǎng)頁運行的腳本，它能夠?qū)崿F(xiàn)對網(wǎng)絡(luò)請求進行緩存，并向網(wǎng)頁推送和同步信息的功能，令人更加興奮的是，它可以實現(xiàn)離線的情況下，也能看到我們的網(wǎng)頁，極大提升了我們的用戶體驗。

service worker 已經(jīng)得到越來越多的瀏覽器的支持，包括蘋果、騰訊的X5內(nèi)核。蘋果從safari11開始，已經(jīng)開始支持了。支持情況如下：

workbox 是 GoogleChrome 團隊推出的一套 Web App 靜態(tài)資源和請求結(jié)果的本地存儲的解決方案，該解決方案包含一些 Js 庫和構(gòu)建工具，在 Chrome Submit 2017 上首次隆重面世。而在 workbox 背后則是 Service Worker 和 Cache API 等技術(shù)和標準在驅(qū)動。在 Workebox 之前，GoogleChrome 團隊較早時間推出過 sw-precache 和 sw-toolbox 庫，但是在 GoogleChrome 工程師們看來，workbox 才是真正能方便統(tǒng)一的處理離線能力的更完美的方案，所以停止了對 sw-precache 和 sw-toolbox 的維護。那workbox能解決什么問題呢？

在service worker中，如果我們要攔截并代理所有的請求，需要我們手動去維護一套緩存列表。但是現(xiàn)在前端開發(fā)，多數(shù)用webpack、gulp、grant來構(gòu)建前端的代碼，導致我們的文件名可能會經(jīng)常發(fā)生，這個時候，特別是中大型的多頁應(yīng)用，緩存列表的內(nèi)容可能會非常多，手動維護就顯得非常麻煩，維護成本也變得很高。

這個時候，workbox的橫空出世，就是為了解決上面的問題。

不管你的站點是哪種方式構(gòu)建的，都可以實現(xiàn)離線緩存的效果；

自動管理好緩存列表，包括更新、同步、刪除舊的緩存等；

配置簡單卻不失靈活，可以完全自定義相關(guān)需求（支持 Service Worker 相關(guān)的特性如 Web Push, Background sync 等）。

針對各種應(yīng)用場景的多種緩存策略。

下面來看下workbox的例子。

1.在入口頁面的onload中，注冊一個service worker，注冊時引入緩存列表文件，也就是build.sw.js。
index.html

我們來看下build.sw.js文件的內(nèi)容，主要包含緩存列表和緩存策略。這里面的內(nèi)容不用我們手動生成，workbox有三種方式生成，我們可以使用workbox-webpack-plugin、workbox-cli、workbox-build。我們暫不討論具體的實現(xiàn)，在這里，我們先來了解一下預(yù)緩存列表和緩存策略這兩個東西。
預(yù)緩存列表
如果我們要緩存靜態(tài)資源，平時不會經(jīng)常更新，只有到發(fā)版時才會修改了資源的hash值，才需要重新更新的，那那 precache 預(yù)緩存應(yīng)該是你所期待的。
workbox 提供了一種非常方便的 API 幫助我們解決 precache 的問題，我們可以使用workbox.precaching來配置，配置格式如下：
workbox.precaching.precacheAndRoute([
  {
    "url": "將要預(yù)緩存的文件 URL",
    "revision": "緩存的hash值"
  },
])
 路由請求緩存
路由請求緩存是指通過對匹配路由給文件采取不用的緩存方式，這個可以通過workbox.routing.registerRoute來進行配置。 路由匹配的方式有三種：
1.通過字符串的方式進行匹配
// 可以直接是當前項目下的絕對路徑
workbox.routing.registerRoute(
    "path/to/logo.png",
    handler // handler 是做緩存策略的回調(diào)函數(shù)，通常指后面所會降到的 "緩存策略函數(shù)"
);

// 也可以是完整的帶完整 host 的 URL 路徑，這里的 URL 必須是 https 的
workbox.routing.registerRoute(
    "https://example.com/a/b/c.jpg",
    handler
);
2.通過正則的方式進行匹配
workbox.routing.registerRoute(
    new RegExp(".*.(js|css|jpg|png|gif)"), // 這里是任何正則都行，只要能匹配得上的請求路由地址
    handler
);
3.通過回調(diào)函數(shù)的方式進行匹配
// 通過回調(diào)函數(shù)來匹配請求路由將會讓策略更加靈活
const customFun = ({url, event}) => {
    // 如果請求路由匹配了就返回true，也可以返回一個參數(shù)對象以供 handler 接收處理
    return false;
};

workbox.routing.registerRoute(
    customFun,
    handler
);
 緩存策略 
緩存策略是指對于匹配到的路由，采取何種方式進行緩存。 workbox提供了兩種配置緩存策略的方式

通過 workbox.strategies API 提供的 緩存策略。
提供一個自定義返回帶有返回結(jié)果的 Promise 的回調(diào)方法。

以下介紹workbox默認提供的幾種緩存策略，包含有五種，分別是：

Stale While Revalidate
Network First
Cache First
Network Only
Cache Only

 Stale While Revalidate 
這種策略的意思是當請求的路由有對應(yīng)的 Cache 緩存結(jié)果就直接返回，在返回 Cache 緩存結(jié)果的同時會在后臺發(fā)起網(wǎng)絡(luò)請求拿到請求結(jié)果并更新 Cache 緩存，如果本來就沒有 Cache 緩存的話，直接就發(fā)起網(wǎng)絡(luò)請求并返回結(jié)果。 使用方式如下：
workbox.routing.registerRoute(
    match, // 匹配的路由
    workbox.strategies.staleWhileRevalidate()
);
 Network First
這種策略就是當請求路由是被匹配的，就采用網(wǎng)絡(luò)優(yōu)先的策略，也就是優(yōu)先嘗試拿到網(wǎng)絡(luò)請求的返回結(jié)果，如果拿到網(wǎng)絡(luò)請求的結(jié)果，就將結(jié)果返回給客戶端并且寫入 Cache 緩存，如果網(wǎng)絡(luò)請求失敗，那最后被緩存的 Cache 緩存結(jié)果就會被返回到客戶端 使用方式如下：
workbox.routing.registerRoute(
    match, // 匹配的路由
    workbox.strategies.networkFirst()
);
 Cache First
這個策略的意思就是當匹配到請求之后直接從 Cache 緩存中取得結(jié)果，如果 Cache 緩存中沒有結(jié)果，那就會發(fā)起網(wǎng)絡(luò)請求，拿到網(wǎng)絡(luò)請求結(jié)果并將結(jié)果更新至 Cache 緩存，并將結(jié)果返回給客戶端。
workbox.routing.registerRoute(
    match, // 匹配的路由
    workbox.strategies.cacheFirst()
);
 Network Only
比較直接的策略，直接強制使用正常的網(wǎng)絡(luò)請求，并將結(jié)果返回給客戶端，這種策略比較適合對實時性要求非常高的請求。
workbox.routing.registerRoute(
    match, // 匹配的路由
    workbox.strategies.networkOnly()
);
 Cache Only
這個策略也比較直接，直接使用 Cache 緩存的結(jié)果，并將結(jié)果返回給客戶端，這種策略比較適合一上線就不會變的靜態(tài)資源請求。
workbox.routing.registerRoute(
    match, // 匹配的路由
    workbox.strategies.cacheOnly()
);
四. 使用workerbox后的效果
在我們的項目中，我們以DomContentLoaded的時間作為參考點，對比有加service worker 和未加的service worker情況。
測試條件
以首頁為例，在不同的網(wǎng)絡(luò)環(huán)境下，發(fā)起10次網(wǎng)絡(luò)請求，然后取平均值，作為它們的最終結(jié)果，測試結(jié)果如下：

通過上面的數(shù)據(jù)可以得出幾個結(jié)論:

在弱環(huán)境下，service worker的優(yōu)勢越發(fā)明顯，
即使在wifi環(huán)境下面，由于存在緩存的情況，瀏覽器加載的速度也比未使用service worker的時間要短。
在無網(wǎng)絡(luò)環(huán)境的情況，也可以做到離線緩存的效果，極大地提升頁面的用戶體驗。

五. 幾個注意點
在使用workbox的過程中，會遇到一些問題，下面列出幾點，也算是做個總結(jié)：
1. service worker 注冊文件放置的位置
在頁面注冊service worker的時候，盡量注冊到項目的根目錄下，這樣才能最大的發(fā)揮service worker的作用
// build.sw.js最好放在項目的根目錄下，才能發(fā)揮最大的緩存效果
navigator.serviceWorker.register(`./build.sw.js`)

// 如果這樣配置的話，就只有path目錄下面的文件才能實現(xiàn)緩存，其他目錄，包括根目錄的都不能緩存
navigator.serviceWorker.register(`./path/build.sw.js`)
2.使用workbox 命令行生成預(yù)緩存列表的注意點
我們先預(yù)設(shè)一下應(yīng)用場景：假設(shè)你的項目在目錄 /app 下，必須保證在你的項目根目錄下有一個 app/sw.js 包含以下內(nèi)容：
// 通常項目中的 sw.js 源文件都是通過這樣預(yù)留一個空數(shù)組的方式來預(yù)緩存內(nèi)容列表的
workbox.precaching.precacheAndRoute([]);
這樣才能保證能將生成的預(yù)緩存內(nèi)容列表內(nèi)容注入到 Service Worker 文件中。
3.緩存策略設(shè)置
在經(jīng)過一段時間的使用和思考以后，給出認為較為合理的緩存策略：

HTML，如果想讓頁面離線可以訪問，使用 NetworkFirst，如果不需要離線訪問，使用 NetworkOnly，其他策略均不建議對 HTML 使用。
CSS 和 JS，情況比較復雜，因為一般站點的 CSS，JS 都在 CDN 上，SW 并沒有辦法判斷從 CDN 上請求下來的資源是否正確（HTTP 200），如果緩存了失敗的結(jié)果，問題就大了。建議使用 Stale-While-Revalidate 策略，既保證了頁面速度，即便失敗，用戶刷新一下就更新了。
如果CSS，JS 與站點在同一個域下，并且文件名中帶了 Hash 版本號，那可以直接使用 Cache First 策略。
圖片建議使用 Cache First，并設(shè)置一定的失效事件，請求一次就不會再變動了。

如果大家在使用過程中有更友好的策略，麻煩也貢獻你們的策略，大家共同學習，共同進步。
還有，要牢記，對于不在同一域下的任何資源，絕對不能使用 Cache only 和 Cache first。
4.service worker的運行環(huán)境
需要注意的是，Service Worker 腳本除了域名為 localhost 時能運行在 http 協(xié)議下以外，只能運行 https 協(xié)議下。
5. 使用Service Worker緩存請求時，POST請求無法緩存
Google對web的標準化還是遵循的，SW認為POST請求就是象服務(wù)器提交資源，不存在緩存需求

參考文檔：
https://developers.google.com...
https://zoumiaojiang.com/arti...