Chrome 调整 BFCache 缓存行为，引起争议

Google 正在对 Chrome 浏览器前进和后退功能的往返缓存（BFCache）行为进行重大调整，即使网站管理员明确禁止在浏览器中缓存页面，也可能将网页存储在缓存中。

BFCache 是一种内存缓存，可以在用户离开时存储页面的完整快照，包括 JavaScript 堆。有了内存中的整个页面，在用户返回时，浏览器就可以迅速、轻松地恢复页面状态。

Google Web.dev 网站对往返缓存的解释

网站管理员通常可以使用Cache-Control标头来规定网页在浏览器缓存中的存储方式。使用Cache-Control: no-store标头，能够阻止浏览器将网页响应存储在本地缓存中。但是问题来了，如果浏览器遵循这一标头，网页就无法存储到 BFCache 中，可能导致在 Chrome 中点击后退和前进按钮时遇到性能问题。

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 浏览器的开发人员希望在不损害用户安全和隐私的前提下，创造出响应速度更快的浏览体验。这一举措旨在平衡开发人员的期望和用户的体验，确保在提升浏览速度的同时，不破坏既定的开发者承诺。

</article