借用workbox实现离线缓存应用

摘要：已经得到越来越多的浏览器的支持，包括苹果腾讯的内核。苹果从开始，已经开始支持了。针对各种应用场景的多种缓存策略。在无网络环境的情况，也可以做到离线缓存的效果，极大地提升页面的用户体验。

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

service worker是在浏览器后台独立于网页运行的脚本，它能够实现对网络请求进行缓存，并向网页推送和同步信息的功能，令人更加兴奋的是，它可以实现离线的情况下，也能看到我们的网页，极大提升了我们的用户体验。

service worker 已经得到越来越多的浏览器的支持，包括苹果、腾讯的X5内核。苹果从safari11开始，已经开始支持了。支持情况如下：

workbox 是 GoogleChrome 团队推出的一套 Web App 静态资源和请求结果的本地存储的解决方案，该解决方案包含一些 Js 库和构建工具，在 Chrome Submit 2017 上首次隆重面世。而在 workbox 背后则是 Service Worker 和 Cache API 等技术和标准在驱动。在 Workebox 之前，GoogleChrome 团队较早时间推出过 sw-precache 和 sw-toolbox 库，但是在 GoogleChrome 工程师们看来，workbox 才是真正能方便统一的处理离线能力的更完美的方案，所以停止了对 sw-precache 和 sw-toolbox 的维护。那workbox能解决什么问题呢？

在service worker中，如果我们要拦截并代理所有的请求，需要我们手动去维护一套缓存列表。但是现在前端开发，多数用webpack、gulp、grant来构建前端的代码，导致我们的文件名可能会经常发生，这个时候，特别是中大型的多页应用，缓存列表的内容可能会非常多，手动维护就显得非常麻烦，维护成本也变得很高。

这个时候，workbox的横空出世，就是为了解决上面的问题。

不管你的站点是哪种方式构建的，都可以实现离线缓存的效果；

自动管理好缓存列表，包括更新、同步、删除旧的缓存等；

配置简单却不失灵活，可以完全自定义相关需求（支持 Service Worker 相关的特性如 Web Push, Background sync 等）。

针对各种应用场景的多种缓存策略。

下面来看下workbox的例子。

1.在入口页面的onload中，注册一个service worker，注册时引入缓存列表文件，也就是build.sw.js。
index.html

我们来看下build.sw.js文件的内容，主要包含缓存列表和缓存策略。这里面的内容不用我们手动生成，workbox有三种方式生成，我们可以使用workbox-webpack-plugin、workbox-cli、workbox-build。我们暂不讨论具体的实现，在这里，我们先来了解一下预缓存列表和缓存策略这两个东西。
预缓存列表
如果我们要缓存静态资源，平时不会经常更新，只有到发版时才会修改了资源的hash值，才需要重新更新的，那那 precache 预缓存应该是你所期待的。
workbox 提供了一种非常方便的 API 帮助我们解决 precache 的问题，我们可以使用workbox.precaching来配置，配置格式如下：
workbox.precaching.precacheAndRoute([
  {
    "url": "将要预缓存的文件 URL",
    "revision": "缓存的hash值"
  },
])
 路由请求缓存
路由请求缓存是指通过对匹配路由给文件采取不用的缓存方式，这个可以通过workbox.routing.registerRoute来进行配置。 路由匹配的方式有三种：
1.通过字符串的方式进行匹配
// 可以直接是当前项目下的绝对路径
workbox.routing.registerRoute(
    "path/to/logo.png",
    handler // handler 是做缓存策略的回调函数，通常指后面所会降到的 "缓存策略函数"
);

// 也可以是完整的带完整 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.通过回调函数的方式进行匹配
// 通过回调函数来匹配请求路由将会让策略更加灵活
const customFun = ({url, event}) => {
    // 如果请求路由匹配了就返回true，也可以返回一个参数对象以供 handler 接收处理
    return false;
};

workbox.routing.registerRoute(
    customFun,
    handler
);
 缓存策略 
缓存策略是指对于匹配到的路由，采取何种方式进行缓存。 workbox提供了两种配置缓存策略的方式

通过 workbox.strategies API 提供的 缓存策略。
提供一个自定义返回带有返回结果的 Promise 的回调方法。

以下介绍workbox默认提供的几种缓存策略，包含有五种，分别是：

Stale While Revalidate
Network First
Cache First
Network Only
Cache Only

 Stale While Revalidate 
这种策略的意思是当请求的路由有对应的 Cache 缓存结果就直接返回，在返回 Cache 缓存结果的同时会在后台发起网络请求拿到请求结果并更新 Cache 缓存，如果本来就没有 Cache 缓存的话，直接就发起网络请求并返回结果。 使用方式如下：
workbox.routing.registerRoute(
    match, // 匹配的路由
    workbox.strategies.staleWhileRevalidate()
);
 Network First
这种策略就是当请求路由是被匹配的，就采用网络优先的策略，也就是优先尝试拿到网络请求的返回结果，如果拿到网络请求的结果，就将结果返回给客户端并且写入 Cache 缓存，如果网络请求失败，那最后被缓存的 Cache 缓存结果就会被返回到客户端 使用方式如下：
workbox.routing.registerRoute(
    match, // 匹配的路由
    workbox.strategies.networkFirst()
);
 Cache First
这个策略的意思就是当匹配到请求之后直接从 Cache 缓存中取得结果，如果 Cache 缓存中没有结果，那就会发起网络请求，拿到网络请求结果并将结果更新至 Cache 缓存，并将结果返回给客户端。
workbox.routing.registerRoute(
    match, // 匹配的路由
    workbox.strategies.cacheFirst()
);
 Network Only
比较直接的策略，直接强制使用正常的网络请求，并将结果返回给客户端，这种策略比较适合对实时性要求非常高的请求。
workbox.routing.registerRoute(
    match, // 匹配的路由
    workbox.strategies.networkOnly()
);
 Cache Only
这个策略也比较直接，直接使用 Cache 缓存的结果，并将结果返回给客户端，这种策略比较适合一上线就不会变的静态资源请求。
workbox.routing.registerRoute(
    match, // 匹配的路由
    workbox.strategies.cacheOnly()
);
四. 使用workerbox后的效果
在我们的项目中，我们以DomContentLoaded的时间作为参考点，对比有加service worker 和未加的service worker情况。
测试条件
以首页为例，在不同的网络环境下，发起10次网络请求，然后取平均值，作为它们的最终结果，测试结果如下：

通过上面的数据可以得出几个结论:

在弱环境下，service worker的优势越发明显，
即使在wifi环境下面，由于存在缓存的情况，浏览器加载的速度也比未使用service worker的时间要短。
在无网络环境的情况，也可以做到离线缓存的效果，极大地提升页面的用户体验。

五. 几个注意点
在使用workbox的过程中，会遇到一些问题，下面列出几点，也算是做个总结：
1. service worker 注册文件放置的位置
在页面注册service worker的时候，尽量注册到项目的根目录下，这样才能最大的发挥service worker的作用
// build.sw.js最好放在项目的根目录下，才能发挥最大的缓存效果
navigator.serviceWorker.register(`./build.sw.js`)

// 如果这样配置的话，就只有path目录下面的文件才能实现缓存，其他目录，包括根目录的都不能缓存
navigator.serviceWorker.register(`./path/build.sw.js`)
2.使用workbox 命令行生成预缓存列表的注意点
我们先预设一下应用场景：假设你的项目在目录 /app 下，必须保证在你的项目根目录下有一个 app/sw.js 包含以下内容：
// 通常项目中的 sw.js 源文件都是通过这样预留一个空数组的方式来预缓存内容列表的
workbox.precaching.precacheAndRoute([]);
这样才能保证能将生成的预缓存内容列表内容注入到 Service Worker 文件中。
3.缓存策略设置
在经过一段时间的使用和思考以后，给出认为较为合理的缓存策略：

HTML，如果想让页面离线可以访问，使用 NetworkFirst，如果不需要离线访问，使用 NetworkOnly，其他策略均不建议对 HTML 使用。
CSS 和 JS，情况比较复杂，因为一般站点的 CSS，JS 都在 CDN 上，SW 并没有办法判断从 CDN 上请求下来的资源是否正确（HTTP 200），如果缓存了失败的结果，问题就大了。建议使用 Stale-While-Revalidate 策略，既保证了页面速度，即便失败，用户刷新一下就更新了。
如果CSS，JS 与站点在同一个域下，并且文件名中带了 Hash 版本号，那可以直接使用 Cache First 策略。
图片建议使用 Cache First，并设置一定的失效事件，请求一次就不会再变动了。

如果大家在使用过程中有更友好的策略，麻烦也贡献你们的策略，大家共同学习，共同进步。
还有，要牢记，对于不在同一域下的任何资源，绝对不能使用 Cache only 和 Cache first。
4.service worker的运行环境
需要注意的是，Service Worker 脚本除了域名为 localhost 时能运行在 http 协议下以外，只能运行 https 协议下。
5. 使用Service Worker缓存请求时，POST请求无法缓存
Google对web的标准化还是遵循的，SW认为POST请求就是象服务器提交资源，不存在缓存需求

参考文档：
https://developers.google.com...
https://zoumiaojiang.com/arti...