借用workbox实现离线缓存应用

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

一. service worker

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

service worker 已经得到越来越多的浏览器的支持,包括苹果、腾讯的X5内核。苹果从safari11开始,已经开始支持了。支持情况如下:
借用workbox实现离线缓存应用

二. 为什么要用workbox

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的横空出世,就是为了解决上面的问题。

workbox的一些特性:

  • 不管你的站点是哪种方式构建的,都可以实现离线缓存的效果;
  • 自动管理好缓存列表,包括更新、同步、删除旧的缓存等;
  • 配置简单却不失灵活,可以完全自定义相关需求(支持 Service Worker 相关的特性如 Web Push, Background sync 等)。
  • 针对各种应用场景的多种缓存策略。

三. workbox的使用

下面来看下workbox的例子。

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

<script>
// Register A service worker
if ('serviceWorker' in navigator) {
  window.addEventListener('load', function() {
    navigator.serviceWorker.register(`./build.sw.js`)
  .then(function(registration) {
    // Registration was successful
    console.log('[success] register ')
  }, function(err) {
    // registration failed :(
    console.log('[fail]: ', err);
  });
  });
 <script>
}

2.在build.sw.js页面配置缓存列表和缓存策略

// 首先引入 Workbox 框架
importScripts('https://storage.googleapis.com/workbox-cdn/releases/3.3.0/workbox-sw.js');

// 注册成功后要立即缓存的资源列表
workbox.precaching.precacheAndRoute([
  {
    "url": "css/index.css",
    "revision": "835ba5c3"
  },
  {
    "url": "images/xxx.png",
    "revision": "b1537bfs"
  },
  {
    "url": "index.html",
    "revision": "b331f695"
  },
  {
    "url": "js/index.js",
    "revision": "4d562866"
  }
]);

// 缓存策略
workbox.routing.registerRoute(
  new RegExp(''.*\.html'),
  workbox.strategies.networkFirst()
);

workbox.routing.registerRoute(
  new RegExp('.*\.(?:js|css)'),
  workbox.strategies.cacheFirst()
);

workbox.routing.registerRoute(
  new RegExp('https://your\.cdn\.com/'),
  workbox.strategies.staleWhileRevalidate()
);

workbox.routing.registerRoute(
  new RegExp('https://your\.img\.cdn\.com/'),
  workbox.strategies.cacheFirst({
    cacheName: 'example:img'
  })
);

实现的效果如下:
借用workbox实现离线缓存应用

我们来看下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次网络请求,然后取平均值,作为它们的最终结果,测试结果如下:

借用workbox实现离线缓存应用

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

  • 在弱环境下,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...

相关推荐