新服务工作者的sw-precache激活是否可以保证缓存破坏？

Question

我使用sw-precache以及sw-toolbox允许的角度应用的缓存页面的离线浏览.

该应用程序通过节点快速服务器提供.

我们遇到的一个问题是,index.html有时似乎没有在缓存中更新,尽管其他资产已在激活新服务工作者时更新.

这会使用户过时index.html,在这种情况下尝试加载不再存在的版本化资产/scripts/a387fbeb.modules.js.

我不完全确定发生了什么,因为似乎在index.html已正确更新的不同浏览器上具有相同的哈希值.

在一个浏览器过时(有问题)Index.html

(缓存2cdd5371d1201f857054a716570c1564哈希)包括:

<script src="scripts/a387fbeb.modules.js"></script>

在其内容中.(此文件不再存在于缓存中或远程上).

在另一个浏览器上更新(好)index.html

(缓存相同2cdd5371d1201f857054a716570c1564)包括:

<script src="scripts/cec2b711.modules.js"></script>

这两个具有相同的缓存,尽管返回给浏览器的内容是不同的!

我应该怎么做？这是否意味着sw-precache当新的SW激活时,不保证原子缓存破坏？怎么能保护这个呢？

如果这些有帮助,这是生成的service-worker.js文件sw-precache.

注意:我意识到我可以使用remoteFirst策略(至少为index.html)来避免这种情况.但我仍然希望了解并找出一种使用cacheFirst策略来充分发挥性能的方法.

注2:我在其他相关问题中看到,可以更改缓存的名称以强制破坏所有旧缓存.但这似乎超越了sw-precache仅破坏更新内容的想法？这是要走的路吗？

注3:请注意,即使我很难重新加载网站被破坏的浏览器.该站点可以工作,因为它会跳过服务工作者缓存,但缓存仍然是错误的 - 服务工作者似乎没有激活 - 我猜是因为这个特定的SW已经被激活但是在正确破坏缓存时失败了.随后的非硬刷新访问仍然会看到破碎index.html.

Answer 1

（这里的答案是特定于sw-precache库的。这些细节通常不适用于服务工作者，但有关缓存维护的概念可能仍然适用于更广泛的受众。）

如果 的内容index.html是由服务器动态生成的，并且依赖于内联或通过<script>或<link>标记引用的其他资源，那么您需要通过该dynamicUrlToDependencies选项指定这些依赖项。以下是作为库的一部分提供的app-shell-demo示例：

dynamicUrlToDependencies: {
  '/shell': [
    ...glob.sync(`${BUILD_DIR}/rev/js/**/*.js`),
    ...glob.sync(`${BUILD_DIR}/rev/styles/all*.css`),
    `${SRC_DIR}/views/index.handlebars`
  ]
}

（/shell此处使用 代替/index.html，因为这是用于访问缓存的 App Shell 的 URL。）

此配置表明sw-precache，每当与这些模式匹配的任何本地文件发生更改时，都应更新动态页面的缓存条目。

如果您的index.html文件不是由服务器动态生成的，而是在构建时使用类似这种方法进行更新，那么确保构建过程中运行的步骤在sw-precache所有其他修改和替换完成之后发生就很重要地方。这意味着使用类似的方法run-sequence来确保服务工作线程生成不会与其他任务并行运行。

如果上述信息对您没有帮助，请随时提交包含更多详细信息（包括您网站的 URL）的错误。