Google 正在对 Chrome 浏览器前进和后退功能的往返缓存(BFCache)行为进行重大调整,即使网站管理员明确禁止在浏览器中缓存页面,也可能将网页存储在缓存中。
BFCache 是一种内存缓存,可以在用户离开时存储页面的完整快照,包括 JavaScript 堆。有了内存中的整个页面,在用户返回时,浏览器就可以迅速、轻松地恢复页面状态。
Google Web.dev 网站对往返缓存的解释
网站管理员通常可以使用Cache-Control
标头来规定网页在浏览器缓存中的存储方式。使用Cache-Control: no-store
标头,能够阻止浏览器将网页响应存储在本地缓存中。但是问题来了,如果浏览器遵循这一标头,网页就无法存储到 BFCache 中,可能导致在 Chrome 中点击后退和前进按钮时遇到性能问题。
Google 正在调整这一行为,以便更好地处理这类情况。
Chrome 将为 BFCache 忽略 no-store头信息
为了解决这个问题,Google 提出了一个建议:即便在 HTTPS 网页上使用了Cache-Control: no-store
标头,也应该能够将页面存储在 BFCache 中。
正方观点
在这个建议方案中,如果 Cookie 没有发生变化,那么浏览器的 HTTP 请求和访问决策就会保持一致。挑战在于,服务器端的变更可能导致访问权限的丧失。
对于使用 EventSource 等技术来反映页面变化的网站来说,这些更新会触发 BFCache 的驱逐,或者在恢复后立即传递事件。相比之下,对于没有即时更新机制的网站来说,用户有可能访问到过时的数据,而提议的 BFCache 行为有可能会加剧这种风险。
Google 目前正在积极努力解决这些问题,首先在测试渠道推出该功能,并收集足够的数据以了解对用户体验的影响。这一过程将有助于优化和调整,确保 BFCache 的实施不会对网站产生不良影响。
反方观点
一些人对这一变化表示担忧,认为Cache-Control: no-store
标头就意味着浏览器不应缓存网页,Google 的这种操作可能会违背对网页开发者的承诺。
在我看来,这似乎触及了一个敏感区域,我不确定这在现实世界中会产生怎样的效果。即使 cache-control: no-store 被严重过度使用,而且列出的数字似乎也表明情况确实如此,难道没有向 Web 开发人员承诺过,一旦页面不再显示,这样的资源就会永远消失吗?难道这是一个可以合理违背的承诺吗?
Opera 开发人员 Daniel Bratell
这个标头只是承诺不在常规浏览器缓存中存储网页,而不是 BFCache。CCNS 并没有明确承诺防止 BFCaching。CCNS 标头,或者一般来说,所有的 Cache-Control 指令,都是为了控制 HTTP 缓存,所以明确的承诺是关于 HTTP 缓存的。
Google 工程师 Fergal Daly
通过重新定义 BFCache 与Cache-Control: no-store
指令的交互方式,Google Chrome 浏览器的开发人员希望在不损害用户安全和隐私的前提下,创造出响应速度更快的浏览体验。这一举措旨在平衡开发人员的期望和用户的体验,确保在提升浏览速度的同时,不破坏既定的开发者承诺。
最新评论
需要管理员权限
直接降级 Windows10 一次性永久解决问题
我按照作者的方法成功了
使用PowerShell修改失败,禁止访问