使用Service Worker Cache API和常规浏览器缓存有什么区别?

Joe*_*ini 45 service-worker progressive-web-apps

在我的Progressive Web App中,我应该在服务工作者中使用Cache API来获取我的静态资产,还是应该依赖浏览器的本机缓存控制?有什么不同?

Joe*_*ini 26

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

  • 提出的一条评论与此有关.如果使用缓存头来缓存页面上的元素,则用户触发刷新将使浏览器跳过HTTP缓存.SW fetch事件将始终拦截请求,这意味着如果您愿意,您始终可以从缓存中提供服务. (9认同)
  • @GauntFace确实,它不仅仅是对一个打开标签的明确"刷新".如果页面使用标头缓存且设备处于脱机状态,则隐式"刷新"(如在新选项卡中加载页面)将失败. (3认同)

Chr*_*ove 18

主要区别在于控制.浏览器缓存是从Cache-Control标头驱动的,这很好,直到它没有.管理网络可寻址资源的缓存方式有各种策略; 私人的,公共的; 生活的时间等

通过服务工作者缓存,您可以以编程方式控制这些资产的持久性.但这意味着你的负担.

浏览器缓存是我认为不可靠的.浏览器将根据设备存储可用性自动清除资产.例如,iPhone用于忽略超过25kb的任何资源的缓存.今天我认为他们非常积极.

我知道Facebook团队几年前做了一项研究,发现他们希望浏览器基于标题缓存的文件中只有25%是缓存的.这意味着有额外的网络流量和服务器活动.

这就是服务工作者缓存是更好的选择.不要删除缓存标题,只是不要依赖它们.

  • 我相信这是你正在为任何感兴趣的人所讨论的研究:https://code.fb.com/web/web-performance-cache-efficiency-exercise/ (5认同)
  • 你确定25%这个数字吗?从上面评论中的链接来看,情况正好相反:“所有记录的请求的 25.5% 缺少缓存”,这意味着 75% 的文件已缓存,25% 的文件没有缓存。 (2认同)