Chrome DevTools 如何验证页面能否命中 bfcache：Run Test 与失败原因定位

页面明明点了浏览器后退，用户却还要等一遍资源重新加载，先别急着改缓存头。Chrome DevTools 已经把 bfcache（Back-forward Cache）检测放进了 Application 面板：它会模拟离开页面再返回，并把“成功恢复”或“没有恢复”的原因直接列出来。下面只走一条可验收的路径，目标是完成一次 Run Test，并知道失败后该看什么。

步骤一：打开 Chrome DevTools 的 Back-forward Cache 面板

先在 Chrome 打开要检查的网页，再用右键“检查”或快捷键打开 DevTools。左侧面板选择 Application，在中间的 Background services 等区域不要停留，继续找到 Back-forward Cache。官方页面给出的入口名称就是这一组英文，版本不同也只是面板排列略有差异。

入口找对的判断很简单：面板标题应为 Back-forward Cache，正文区域出现 Run Test。如果你测试的是单页应用内部的软路由切换，要先换成真正会离开当前文档的链接；bfcache 针对的是浏览器管理的前进后退导航。

步骤二：点击 Run Test 触发一次真实的前进后退

点击 Run Test 后保持当前标签页打开。DevTools 会尝试导航到别处，再返回原页面，然后把恢复情况写在结果卡片里。这个动作不是刷新，也不是只看 Network 请求；它要验证页面能否作为整体从内存快照恢复。

如果结果停在加载中，先确认页面确实有可用的跨页面导航，再重新点击一次；不要连续开多个测试。正式记录时把页面版本、浏览器版本和结果状态一并写下，后续复测才有可比性。

步骤三：展开失败原因并识别 Actionable 项

看到 Not restored 不等于页面只能放弃 bfcache。展开失败原因列表，先看标记为 Actionable 的项目。它表示开发者可以通过代码、响应头或页面结构调整来改善，而不是让你凭感觉反复改配置。

常见线索包括页面或第三方脚本注册了 unload，页面离开时仍持有跨页面共享的 IndexedDB、WebSocket 或未完成请求，也可能是响应头使用了不适合当前页面的缓存策略。这里别急着把所有原因都归到“缓存失效”，先按面板给出的实体名称逐项处理。

步骤四：修复后复测并确认恢复状态

以 unload 为例，页面清理工作更适合放在 pagehide，需要在恢复时更新状态的逻辑则可以观察 pageshow 的 persisted 属性：

window.addEventListener('pagehide', () => {
  closeSharedConnections();
});

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    refreshPageState();
  }
});

保存并部署后，回到同一个页面重新执行 Application → Back-forward Cache → Run Test。验收标准不是“没有红色提示”，而是结果卡片明确显示 Restored from back-forward cache。如果仍然失败，保留新的 Actionable 条目；它比一次盲目刷新更能说明下一步。

还要记住边界：浏览器退出后重新启动、复制标签页、关闭后再打开，以及内存回收，都可能让某次前进后退不使用 bfcache。因此一次成功测试证明的是当前页面和当前环境具备恢复条件，不是永久的 100% 命中承诺。

相关问题

Run Test 和刷新页面有什么区别？

刷新通常会重新发起页面加载；Run Test 会模拟离开再返回，专门检查浏览器能否恢复 bfcache 快照。

为什么成功恢复后还要处理 pageshow？

bfcache 恢复的是内存中的页面状态，购物车、登录态或实时数据可能已经过期，pageshow 可以用来判断是否需要更新。

Actionable 原因都能修好吗？

Actionable 表示页面侧存在可处理线索，但扩展、浏览器生命周期和设备内存等外部条件仍可能影响最终结果。

完成这条路径后，排查重点就从“页面为什么偶尔变慢”落到了一个具体结果：Run Test 是否显示 Restored，以及 Not restored 列表里哪一条 Actionable 原因尚未消失。