如果我将 URL 添加到 waitUntil() 流之外的服务工作者缓存会发生什么？答案

【问题标题】：What happens if I add URLs to service worker cache outside of the waitUntil() flow?如果我将 URL 添加到 waitUntil() 流之外的服务工作者缓存会发生什么？
【发布时间】：2020-06-14 16:24:11
【问题描述】：

我可以在“安装”事件的waitUntil 工作流之外将项目添加到我的 Service Worker 缓存吗？如果这样做会发生什么？这是个坏主意吗？

我有一个单页应用程序，我想在 Service Worker 安装后立即缓存应用程序的主要组件和资产，然后延迟缓存用户可能无法访问的一些辅助页面。如果没有服务人员，我将动态导入这些辅助资产，因此用户无需在首次加载时下载它们。

我目前在做的是这样的：

self.addEventListener("install", e => {

    e.waitUntil(
        (async () => {
            const cache = await caches.open(cacheName);
            return cache.addAll(appShell);
        })()
    );

    caches.open(cacheName).then(cache => {
        return cache.addAll(secondaryPages);
    });
});

secondaryPages 正在被 SW 缓存，但我不确定这是否是最好的方法。我希望上面的代码会说“在缓存 appShell 之前不要完成安装，但不要等待secondaryPages”。

这是否给了我正在寻找的延迟性能提升，或者我应该稍后将secondaryPages 添加到缓存中，比如在客户端加载内容后从应用程序触发的消息事件？

【问题讨论】：

标签： javascript service-worker

【解决方案1】：

我意识到我可以使用 setTimeout 来模拟对二级缓存的缓慢响应，以查看应用的行为方式。

caches.open(cacheName).then(cache => {
    setTimeout(() => {
        cache.addAll(secondaryManifest);
        console.log("added secondary cache");
    }, 1000 * 20);
});

这样，软件就可以正确安装，缓存主应用程序外壳。 20 秒后，辅助文件被缓存，但同时该应用程序完全有用。如果请求需要这些延迟加载文件的页面，它们会通过我设置的常规获取处理（检查缓存，然后在需要时访问网络）。这可能会导致setTimeout 中的cache.addAll 覆盖缓存中的那些项目，但这不应该是一个真正的问题，至少从用户体验的角度来看不是问题，尽管软件可能会重复下载。

所以是的，在waitUntil 之外使用cache.addAll 可以工作，并且只会在后台缓存文件，而应用程序和软件会继续他们的快乐方式。这样可以更高效地安装软件。

【讨论】：