使用 Service Worker Cache API 和常规浏览器缓存有啥区别？

Posted 2023-02-16

【中文标题】使用 Service Worker Cache API 和常规浏览器缓存有啥区别？

【英文标题】：What's the difference between using the Service Worker Cache API and regular browser cache?使用 Service Worker Cache API 和常规浏览器缓存有什么区别？

【发布时间】：2016-05-13 10:56:13

【问题描述】：

在我的 Progressive Web App 中，我应该在 service worker 中使用缓存 API 来处理我的静态资产，还是应该只依赖浏览器的本机缓存控制来处理这些资产？有什么区别？

【参考方案1】：

Service Worker 缓存 API 的一个主要优势是它为您提供比内置浏览器缓存更详细的控制。例如，您的服务工作者可以在用户首次运行您的 Web 应用程序时缓存多个请求，包括他们尚未访问的资产。这将加快后续请求。您还可以实现自己的缓存控制逻辑，确保被认为重要的资产保留在缓存中，同时删除较少使用的数据。

【讨论】：

与此相关的一条评论。如果使用缓存头来缓存页面上的元素，用户触发的刷新将使浏览器跳过 HTTP 缓存。 SW fetch 事件将始终拦截请求，这意味着您可以随时从缓存中提供服务。

@GauntFace 确实如此，而且它不仅在打开标签的显式“刷新”上。如果页面与标题一起缓存并且设备处于脱机状态，则隐式“刷新”（例如在新选项卡中加载页面）将失败。

【参考方案2】：

主要区别在于控制。浏览器缓存被 Cache-Control 标头驱动，这很好，直到它不是。有各种各样的策略来管理如何缓存网络可寻址资源；私人的，公共的；生存时间等。

使用 service worker 缓存，您可以以编程方式控制这些资产的持久化方式。但这意味着负担在你身上。

浏览器缓存是我认为不可靠的。浏览器将根据设备存储可用性自动清除资产。例如，iPhone 过去常常忽略对超过 25kb 的任何资源的缓存。今天我认为他们只是非常具有侵略性。

我知道 Facebook 团队几年前进行了一项研究，发现他们希望浏览器根据标题缓存的文件中只有 25% 被缓存。这意味着存在额外的网络流量和服务器活动。

这就是为什么服务工作者缓存是更好的选择。不要去删除你的缓存头，只是不要依赖它们。

【讨论】：

我相信这是您为任何感兴趣的人谈论的研究：code.fb.com/web/web-performance-cache-efficiency-exercise

你确定那个 25% 的数字吗？从上面评论中的链接看起来是相反的：“所有记录的请求中有 25.5% 缺少缓存”，这意味着 75% 的文件被缓存而 25% 的文件没有。

“浏览器将根据设备存储可用性自动清除资产。” SW 缓存也不能幸免于此。见：developers.google.com/web/ilt/pwa/…