在Workbox中使用skipWaiting和clientsClaim有什么缺点?

作为背景,我建议你阅读 The Service Worker Lifecycle ". 它是从一般服务工作者的角度编写的,但这些要点也适用于以Workbox为动力的服务工作者。

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

如果 skipWaiting 是真的,那么 激活 处理程序负责清除缓存中的旧url,将在安装更新的服务工作程序后立即执行。

在这种情况下,有没有理由不 滑雪等待 是真的吗?

有一个 few risks 使用 滑雪等待 ,为了安全起见,我们在Workbox中默认禁用它。(在旧版本中默认启用, sw-precache -生成的服务工人。)

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

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

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

传统上,要么是HTML本身(要么是一些JavaScript,它包含在页面生命周期早期加载的路由信息),它包含对需要延迟加载的url的当前列表的引用。

假设最初加载的web应用的版本(在服务工作者更新之前)认为 /view-one.abcd1234.js 需要加载才能呈现 /view-one . 但同时,您已经部署了代码的更新,并且 /view-one.abcd1234.js视图 在您的服务器和预处理清单中已被替换为 /view-one.7890abcd.js .

如果 滑雪等待 是真的,那么 /view-one.abcd1234.js视图 将从缓存中清除,作为 激活 事件。作为部署的一部分,您可能已经从服务器中清除了它。所以这个请求会失败。

如果 滑雪等待 是假的,那么 /view-one.abcd1234.js视图 将继续在缓存中可用,直到服务工作者的所有打开的客户端都已关闭。那通常是你想要的。

注意:虽然使用服务工作者可能会使它更容易遇到此类问题,但这是所有延迟加载版本化url的web应用程序的问题。您应该始终进行错误处理,以检测延迟加载失败并尝试通过强制重新加载页面等方式进行恢复。如果您已经准备好了恢复逻辑,并且您对该UX很满意,那么您可以选择启用 滑雪等待 无论如何。

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

这与第一个风险类似,但当您的url中没有散列指纹时,它适用。如果部署到HTML的更新和对其中一个视图的相应更新,则现有客户端可以结束加载 /view-one.js 这与从缓存中获取的HTML的结构不对应。

如果 滑雪等待 是假的,那么这不太可能发生,因为 /视图-one.js 从缓存加载的内容应与从同一缓存加载的HTML结构相对应。这就是为什么违约更安全。

注意:和以前一样,这并不是服务工作者独有的风险动态加载未经版本化的url的任何web应用可能在最近的部署之后加载不兼容的逻辑。

那么clientsClaim做什么呢?

clientsClaim 确保范围内的所有不受控制的客户端(即页面)在服务人员激活后立即由服务人员控制。如果不启用它,则在下一次导航之前不会控制它们。

启用通常比 滑雪等待 ,如果您希望服务工作进程尽早开始填充运行时缓存,则可能会有所帮助。

我会把你介绍给 section 在“服务工作者生命周期”文档中获取更多信息。