使用skipWaiting和clientsClaim与Workbox有什么缺点？

Question

默认情况下skipWaiting,在Workbox中设置为false.假设您仅使用Workbox创建的服务工作程序进行缓存,那么将此设置为true是否有任何缺点？如果不这样做,您的应用程序的下一个版本将发布更新的资源URL(来自webpack).这些URL将在服务工作者的预缓存清单skipWaiting中更新,但没有,更新的服务工作者将不会被激活以利用它们,直到用户关闭其浏览器并重新打开.

这些更新的资源将被正确加载(webpack将加载其中包含新哈希值的资源),但它们永远不会被缓存,直到用户再次关闭运行服务工作者的所有打开的浏览器并重新打开.在这种情况下,有没有理由不设置skipWaiting为真？

作为一个相关的问题,有什么确切不clientsClaim控制？仅通过切换skipWaiting就可以解决上述问题; 那么客户承诺做什么？

Answer 1

作为背景,我建议阅读" 服务工作者生命周期 ".它是从通用服务工作者角度编写的,但这些要点也适用于Workbox支持的服务工作者.

Workbox使用install事件处理程序将新资源添加到临时缓存,并使用activate事件处理程序将这些新资源移动到"活动"缓存,以及删除不再列在预缓存清单中的所有URL.

如果skipWaiting为true,那么activate负责从缓存中清除旧URL的handler将在安装更新的服务工作程序后立即执行.

在这种情况下,有没有理由不设置skipWaiting为真？

这里有几个风险使用skipWaiting,并在安全方面犯了错误,我们默认的针线禁用它.(默认情况下,在旧的,sw-precache生成的服务工作者中启用它.)

让我们假设一个场景,其中HTML首先加载缓存(通常是最佳实践),然后在加载后的某个时间检测到服务工作者更新.

风险1:指纹内容的延迟加载

现代Web应用程序通常结合两种技术:仅在需要时异步延迟加载资源(例如,在单页应用程序中切换到新视图),并添加指纹(散列)以根据URL包含的内容唯一地标识URL.

传统上,它本身就是HTML本身(或者包含路由信息的一些JavaScript,它们也在页面生命周期的早期加载),其中包含对当前需要延迟加载的URL列表的引用.

假设您最初加载的Web应用程序版本(在服务工作者更新发生之前)认为/view-one.abcd1234.js需要加载URL 才能呈现/view-one.但与此同时,您已经部署了对代码的更新,并且/view-one.abcd1234.js已经在您的服务器和预先缓存清单中进行了替换/view-one.7890abcd.js.

如果skipWaiting为true,则将/view-one.abcd1234.js作为activate事件的一部分从缓存中清除.您可能已经从服务器中清除了它,作为部署的一部分.所以请求将失败.

如果skipWaiting为false,/view-one.abcd1234.js则将继续在缓存中提供,直到服务工作者的所有打开的客户端都已关闭.这通常是你想要的.

注意:虽然使用服务工作者可能会使其更容易遇到此类问题,但对于延迟加载版本化URL的所有Web应用程序来说,这是一个问题.您应始终使用错误处理来检测延迟加载失败并尝试通过例如强行重新加载页面来进行恢复.如果你有适当的恢复逻辑,并且你可以使用该UX,那么你可以选择启用它skipWaiting.

风险2:延迟加载不兼容的逻辑

这与第一个风险类似,但适用于您的网址中没有哈希指纹的情况.如果部署更新了自己的HTML和相应的更新到你的观点之一,现有客户可以结束延迟加载一个版本的/view-one.js不对应于HTML的结构是从缓存中提取.

如果skipWaiting为false,则不太可能发生这种情况,因为/view-one.js从缓存加载的内容应该对应于从同一缓存加载的HTML结构.这就是为什么它是一个更安全的默认值.

注意:与之前一样,这不是服务工作者独有的风险 - 任何动态加载未版本化URL的Web应用程序最终可能会在最近部署后加载不兼容的逻辑.

那么客户承诺做什么？

clientsClaim确保服务工作者激活后,服务工作者将立即控制范围内的所有不受控制的客户端(即页面).如果您未启用它,则在下一次导航之前不会对它们进行控制.

skipWaiting如果您希望服务工作者尽快开始填充运行时缓存,那么启用它通常比安装起来更安全,并且可能会有所帮助.

我将向您推荐服务工作者生命周期文档中的部分以获取更多信息.