从缓存提供服务时服务人员速度变慢

Question

我有一些资源想要缓存并以最快的速度提供给我的应用程序。

当我使用 appcache 时，我得到了很好的服务速度，但我被 appcache 卡住了。

所以我用服务人员替换了它。

然后我尝试了最简单的策略，只需在安装时缓存静态资产，并在获取时从缓存中提供它们。

它起作用了，当我检查 chrome 的网络面板时，我很高兴看到我的 service worker 正在运行，但是 - 加载时间很糟糕，每个资源加载时间加倍。

所以我开始考虑其他策略，here 你可以找到很多，缓存和网络竞赛听起来很有趣，但我被数据使用吓倒了。

所以我尝试了一些不同的方法，我试图积极地将资源缓存在服务人员的内存中。每当我的服务工作者启动并运行时，它都会从缓存中汇集相关资源，并将响应对象保存在内存中以备后用。当它获得匹配的 fetch 时，它只会以内存中响应的克隆进行响应。

这个策略被证明是最快的，这是我做的一个比较：

所以我的问题很模糊，因为我对服务人员的理解仍然很模糊......

这一切都有意义吗，我可以将静态资源缓存保留在内存中吗？ 臃肿的内存使用情况如何，这有什么负面影响吗？例如 - 浏览器可能会更频繁地关闭具有高内存消耗的服务工作者。

Answer 1

您不能依赖于将 Response 对象保存在 Service Worker 的内存中，然后直接对其进行响应，原因（至少）有两个：

• Service Worker 的生命周期很短，每次 Service Worker 再次启动时，Service Worker 全局范围内的所有内容都是cleared。
• 您只能读取一次Response 对象的主体。使用Response 对象响应fetch 请求将导致读取其主体。因此，如果您在服务工作者的全局范围被清除之前对同一个 URL 发出了两个请求，那么第二次使用 Response 将失败。 （您可以通过在 Response 上调用 clone() 并使用克隆来响应 fetch 事件来解决此问题，但是这样会带来额外的开销。）

如果您发现从 Service Worker 将响应返回到您的页面的速度明显变慢，我会花一些时间来深入了解您的 Service Worker 代码的实际外观，以及您客户端上的代码页面看起来像。如果您的客户端页面的主要 JavaScript 线程被锁定（例如，由于重量级的 JavaScript 操作需要一段时间才能完成并且永远不会产生），这可能会导致从 service worker 获取响应到客户端页面的延迟。

分享更多关于您如何实现基于缓存的服务工作线程的详细信息将是很好的第一步。