Service Worker Cache 和 HTTP Cache 联合使用的场景讨论
2022/8/4 23:23:12
本文主要是介绍Service Worker Cache 和 HTTP Cache 联合使用的场景讨论,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!
本文基于下列的表格进行讨论。
场景1:Long-term caching (Cache, falling back to network)
-
当缓存资源有效时(<= 30 天):Service Worker 立即返回缓存的资源,无需访问网络。
-
当缓存资源过期(> 30 天)时:Service Worker 去网络获取资源。 浏览器在其 HTTP 缓存中没有资源的副本,因此它在服务器端获取资源。
缺点:在这种情况下,HTTP 缓存提供的价值较小,因为当 Service Worker 中的缓存过期时,浏览器总是会将请求传递给服务器端。
场景2:Medium-term caching (Stale-while-revalidate)
-
当缓存资源有效时(<= 1 天):Service Worker 立即返回缓存的资源,并去网络获取资源。 浏览器在其 HTTP 缓存中有资源的副本,因此它将该副本返回给服务工作者。
-
当缓存资源过期(> 1 天):Service Worker 立即返回缓存的资源,并去网络获取资源。 浏览器在其 HTTP 缓存中没有资源的副本,因此它会在服务器端获取资源。
缺点:Service Worker 需要额外的缓存清除来覆盖 HTTP 缓存,以便充分利用“重新验证”步骤。
场景3:Short-term caching (Network falling back to cache)
-
当缓存的资源有效时(<= 10 分钟):Service Worker 去网络获取资源。 浏览器在其 HTTP 缓存中有资源的副本,因此它会将其返回给服务工作者,而无需进入服务器端。
-
当缓存资源过期(> 10 分钟):Service Worker 立即返回缓存的资源,并去网络获取资源。 浏览器在其 HTTP 缓存中没有资源的副本,因此它会在服务器端获取资源。
与 Medium 缓存场景类似,Service Worker 需要额外的缓存清除逻辑来覆盖 HTTP 缓存,以便从服务器端获取最新资源。
在所有场景下,Service Worker 缓存在网络不稳定的情况下仍然可以返回缓存的资源。 另一方面,当网络不稳定或宕机时,HTTP 缓存是不可靠的。
总之,Service Worker 缓存逻辑不需要与 HTTP 缓存到期逻辑保持一致。 如果可能,在 service worker 中使用更长的过期逻辑来授予 service worker 更多的控制权。
HTTP 缓存仍然发挥着重要作用,但在网络不稳定或宕机时它并不可靠。
这篇关于Service Worker Cache 和 HTTP Cache 联合使用的场景讨论的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!
- 2024-04-16软路由代理问题, tg 无法代理问题-icode9专业技术文章分享
- 2024-04-16程序猿用什么锅-icode9专业技术文章分享
- 2024-04-16自建 NAS 的方案-icode9专业技术文章分享
- 2024-04-14ansible 在远程主机上执行脚本,并传入参数-icode9专业技术文章分享
- 2024-04-14ansible 在远程主机上执行脚本,并传入参数, 加上remote_src: yes 配置-icode9专业技术文章分享
- 2024-04-14ansible 检测远程主机的8080端口,如果关闭,则echo 进程已关闭-icode9专业技术文章分享
- 2024-04-14result 成功怎么写-icode9专业技术文章分享
- 2024-04-14stopped 状态设置为变量,由外部传递进来-icode9专业技术文章分享
- 2024-04-14为什么ansible执行远程脚本需要放到后台-icode9专业技术文章分享
- 2024-04-14shell 正则判断字符串内是否含有th-icode9专业技术文章分享