首页 文章

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

提问于
浏览 次
5

我正在使用 sw-precache 和 sw-toolbox 来允许离线浏览Angular应用程序的缓存页面 .

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

我们遇到的一个问题是 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激活时原子缓存破坏？怎么能保护这个？

如果这些有帮助，这是来自 sw-precache 的generated service-worker.js文件 .

Note ：我意识到我可以使用 remoteFirst 策略（至少对于 index.html ）来避免这种情况 . 但我仍然希望了解并找出一种方法来使用 cacheFirst 策略来充分发挥性能 .

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

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

javascript offline-caching service-worker sw-precache sw-toolbox

1 回答

  • 2

    （这里的答案特定于sw-precache library . 详细信息一般不适用于服务工作者，但有关缓存维护的概念可能仍适用于更广泛的受众 . ）

    如果 index.html 的内容是由服务器动态生成的，并且依赖于通过 <script> 或 <link> 标记内联或引用的其他资源，则需要通过 dynamicUrlToDependencies 选项指定这些依赖项 . 这是作为库的一部分提供的示例from the 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 不是由服务器动态生成的，而是在构建期间使用this approach等更新，那么确保在所有其他修改和替换之后运行 sw-precache 的构建过程中的步骤很重要发生在 . 这意味着使用类似run-sequence的内容来确保服务工作者生成不与其他任务并行运行 .

    如果以上信息对您没有帮助，请随时提供file a bug详细信息，包括您网站的网址 .

    回复于

相关问题