WordPress使用Service Worker加速网站教程

早在去年的时候就准备写WordPress使用Service Worker加速网站的教程，结果一直拖到了现在。本文，就彻底把Service Worker加速网站的方法给写出来。当然，方法也是我四处搜索总结出来的。Service Worker的主要作用在于解放主线程，一般简称SW缓存。做到极致，甚至可以离线浏览网页。不过，本文的主要意图是一定程度上加快网页的访问。

Service Worker的兼容性

下图是Service worker现有的浏览器支持版本，从图上可以看出火狐和谷歌的支持是比较良好的，IE和safari需要相对比较高的版本才能够支持。移动端的话ios也需要从ios13才开始支持在安卓上的支持会相对广泛一点。

Service Worker由来

W3C 组织早在 2014 年 5 月就提出过 Service Worker 这样的一个 HTML5 API ，主要用来做持久的离线缓存。service worker是浏览器的一个高级特性，本质是一个web worker，是独立于网页运行的脚本。 web worker这个api被造出来时，就是为了解放主线程。因为，浏览器中的JavaScript都是运行在单一个线程上，随着web业务变得越来越复杂，js中耗时间、耗资源的运算过程则会导致各种程度的性能问题。而web worker由于独立于主线程，则可以将一些复杂的逻辑交由它来去做，完成后再通过postMessage的方法告诉主线程。 service worker则是web worker的升级版本，相较于后者，前者拥有了持久离线缓存的能力。

Service Worker特点

独立于主线程、在后台运行的脚本
被install后就永远存在，除非被手动卸载
必须是https的协议才能使用。不过在本地调试时，在http://localhost 和http://127.0.0.1 下也是可以跑起来的。
不能直接操纵dom：因为sw是个独立于网页运行的脚本。
可拦截请求和返回，缓存文件。sw可以通过fetch这个api，来拦截网络和处理网络请求，再配合cacheStorage来实现web页面的缓存管理以及与前端postMessage通信。

接下来，就是WordPress使用Service Worker的详细方法介绍了。

Service Worker资源

这一部分我们放在文末提供下载，属于付费资源。当然，你也可以在网上找到相关的文件，然后继续观看本教程。文末提供的文件一共三个，都是Service Worker必须的资源文件以及功能性文件。

Service Worker使用

将文末提供的三个文件，放于WordPress网站根目录，比如data/www/iymark.com目录下

接着，在WordPress主题footer.php文件中加入如下代码，或者在WordPress主题设置-插入代码-页脚代码中加入如下代码。这里，我推荐直接在后台主题设置中，找到插入代码，页脚代码中插入即可。这样，主题更新时，不会有任何影响。

<script>
    var serviceWorkerUri = '/serviceworker.js';

    if ('serviceWorker' in navigator) {  
        navigator.serviceWorker.register(serviceWorkerUri).then(function() {
          if (navigator.serviceWorker.controller) {
            console.log('Assets cached by the controlling service worker.');
          } else {
            console.log('Please reload this page to allow the service worker to handle network operations.');
          }
        }).catch(function(error) {
          console.log('ERROR: ' + error);
        });
    } else {
        console.log('Service workers are not supported in the current browser.');
    }
</script>

上述代码属于Service Worker缓存的引入，不建议做任何修改。如果你实在受不了那些英文，可以改掉console.log后面的描述，那是在f12控制台console输出的结果描述。

Assets cached by the controlling service worker.
- 表明一个成功启动缓存的提示
Please reload this page to allow the service worker to handle network operations.
- 表明你是第一次访问网站，再次点击一个页面，就会成功启动缓存。
Service workers are not supported in the current browser.
- 表明当前浏览器不支持Service Worker缓存

Service Worker修改

请注意，关于我提供的那三个文件，你只能修改serviceworker.js文件，属于简单的配置文件，指定你的哪些资源需要走Service Worker缓存（SW缓存）。

首先，请将serviceworker.js文件中的iymark.com修改为你自己的域名。

    self.toolbox.router.get('wp-content/cache/(.*)', self.toolbox.cacheFirst, {
        cache: {
          name: staticAssetsCacheName,
          maxEntries: maxEntries
        }
    });

serviceworker.js文件中的上述代码，你可以改为你自己静态资源缓存的地方。比如你用了WP Super Cache这款插件，就可以保持这个配置。当然，你也可以多复制几份这个配置代码，添加自己所有静态资源的目录。

    self.toolbox.router.get('/(.*)', self.toolbox.cacheFirst, {
        origin: /cdn\.jsdelivr\.com/,
        cache: {
          name: staticVendorCacheName,
          maxEntries: maxEntries
        }
    });

上述代码为第三方资源添加的方法，可以多复制几份，把所有第三方的域名都添加一遍，注意写法即可。例如：/oss\.iymark\.com/。

Service Worker流程

Service Worker 文件只在首次注册的时候执行了一次。
安装、激活流程也只是在首次执行 Service Worker 文件的时候进行了一次。
首次注册成功的 Service Worker 不能拦截当前页面的请求。
非首次注册的 Service Worker 可以控制当前的页面并能拦截请求。
Service Worker 首次注册或者有新版本触发更新的时候，才会重新创建一个 worker 工作线程并解析执行 Service Worker 文件，在这之后并进入 Service Worker 的安装和激活生命周期

Service Worker展示

首次访问如下图所示：

当你二次访问，或者再访问其他页面时，就会触发Service Worker（SW缓存）。

Service Worker更新

更新一个servicework，最直接的办法就是修改servicework.js这个文件，当刷新浏览器时，浏览器尝试重新下载servicework.js脚本文件，然后会与之前的版本比对，一旦发现文件内容不一致，就会进入更新流程。

新的 servicework 被启动安装并触发 install事件。
安装成功后，新版 servicework 进入等待状态，此时页面的控制权还在老版 servicework手中。
当servicework控制的所有终端都关闭之后，或者手动self.skipWaiting()，旧的 servicework 才能被终止，此时新的servicework被激活，触发activate 事件。
用户再次访问页面，或刷新页面，新的 service work 启动控制页面。