从 0 到 1 上手 bfcache 往返缓存

bfcache（back/forword cache），可称为“往返缓存”，是一种可以实现即时前进、后退导航的浏览器（优化）特性。它能够极大提升用户体验，尤其是针对网络环境或设备速度较慢的用户。

作为开发者，了解如何在各个浏览器中优化页面的 bfcache，对于提升网站的体验非常有帮助。

浏览器兼容性

Firefox 和 Safari 浏览器在桌面和移动设备上均已支持 bfcache 多年。

Chrome 86 针对少数安卓用户开启了跨站导航的 bfcache 功能。在 Chrome 87 中，跨站导航的 bfcache 支持将对所有安卓用户开放，同站导航的 bfcache 功能也将尽快支持。

bfcache 基础知识

bfcache 是一种内存型缓存，在用户导航离开页面时，将当前页面的完整快照（包括 javascript 堆）存储下来。由于整个页面都是存储在内存之中，一旦用户返回，浏览器便可以快速恢复页面。

你一定遇到过这种情况，当访问一个网站时，点击链接跳转到另一个页面，却发现这个页面并不是你想要的，于是点击了浏览器的“后退”按钮。在这种情况下，bfcache 可以给回退页面的加载速度带来巨大的提升。

未启用 bfcache

加载之前页面的时候会发送新的请求，根据页面对重复请求的优化情况不同，浏览器可能会重新下载、解析、执行之前下载过的部分或全部资源。

启用 bfcache

由于整个页面都存储在内存之中，加载之前页面的过程会在瞬间完成，不会有任何网络请求。

以下视频展示了在实际使用中 bfcache 给导航速度带来的巨大提升。

上面视频中启用 bfcache 比不启用 bfcache 的案例要快很多。

bfcahe 不仅可以加速导航，还减少了数据使用量，因为资源无需重复下载。

Chrome 使用数据显示，桌面端 10% 的导航操作、移动端 20% 的导航操作属于前进和后退。随着 bfcache 功能开启，浏览器每天为数十亿网页减少了数据传输和加载时间。

缓存的工作方式

bfcache 的缓存机制与 HTTP 缓存不同（HTTP 缓存在加速重复导航中也很有用）。bfcache 会将完整页面的快照（包括 javascript 堆）放在内存中，而 HTTP 缓存的对象只包含发送的请求。由于加载一个网页的所有请求全部来自 HTTP 缓存的可能性极小，重复访问使用了 bfcache 技术的页面往往比使用非 bfache 技术极致优化过的页面时的导航速度要快得多。

然而，在内存中创建并存储网页快照时，如何保存执行中的代码会有一定复杂性。例如，当页面已经被 bfcache 缓存时，应该如何处理setTimeout()的回调。

答案是，浏览器会暂停所有执行中和等待中的定时器和未被 resolve 的 promise，以及所有 Javascript 任务队列^[1]中的所有待执行任务，等到页面从 bfcache 中恢复时再继续执行中的任务。

在一些场景下这种情况风险较低，比如定时器和 promises，但其他场景中可能会出现令人迷惑的行为和非预期行为。例如，当浏览器暂停了一个含有IndexedDB 事务的任务，他可能会影响到同一来源的其他选项卡（同一个 IndexedDB 数据库可能被多个选项卡同时访问）。因此，在 IndexedDB 事务中间，或者使用可能影响其他页面的 API 时，浏览器通常不会缓存页面。

更多有关各个 API 如何影响页面的 bfcache 使用，请阅读后面“优化页面的 bfcache”的部分。

观察 bfache 的 API

尽管 bfcahce 缓存机制是由浏览器的自动处理，对于开发者来说，了解它的原理仍然非常重要，只有知道缓存在何时发生，才能针对它优化自己的网页以及调整衡量指标。

页面过渡事件^[2]pageshow和pagehide是用于监听 bfcache 的基础事件，它是与 bfcahce 缓存同时存在，并且目前已被大多数浏览器^[3]支持。

全新的网页生命周期^[4]中的freeze和resume事件，在页面从 bfcache 中存储和取出时会被触发。该事件在其他情况下也会被触发， 例如，当背景选项卡被冻结来降低 CPU 功耗时。值得注意的是，这两个生命周期事件只在 Chromium 系列浏览器中得到支持。

观察网页从 bfcache 中恢复

页面最初加载时以及从 bfcache 恢复页面时，pageshow事件都会在会在load事件之后立即触发。如果页面是从 bfcache 中恢复，pageshow事件中的persisted属性的值会是true，反之为false。你可以根据persisted属性的值来判断页面是否是从 bfcache 中恢复。以下为示例代码：

在支持页面生命周期 API 的浏览器中，resume事件会在页面从 bfcache 中恢复时（pageshow事件之前）被触发，尽管用户通过被冻结的背景标签页再次访问时事件也会被触发。如果你想要从冻结状态恢复到页面的激活状态（包括在 bfcache 中的页面），可以使用resume事件，但如果你想要统计网站加载的 bfcache 命中率，需要使用pageshow事件。有些情况下，可能二者都需要。

在“对性能和分析的影响”部分查看更多 bfcache 测量的最佳实践。

观察页面进入 bfcache

pagehide事件与pageshow事件相对。pageshow事件在页面正常加载时以及从 bfcache 中恢复时被触发。pagehide事件则在页面被卸载时已近浏览器将页面存入 bfcache 是被触发。

pagehide事件同样有persisted属性，当属性值为false时可以确定页面并不会进入 bfcache 缓存。而当persisted属性的值为true时，并不能保证页面一定对被缓存。这意味着浏览器试图将页面缓存，但可能会由于一些因素导致无法进行缓存。

类似的，freeze事件会在pagehide事件之后立即触发（persisted属性为true时），但同样这只意味着浏览器试图缓存页面。他仍有可能因为一些原因（下文将介绍）而不进行缓存。

针对 bfcache 优化你的页面

并不是所有页面都会存储在 bfcache 中，甚至当页面已被存储在其中， 也并不是永久性的。开发者有必要了解 bfcache 存储页面的条件，从而提高缓存命中率。

以下的内容列出了让浏览器尽可能缓存网页的最佳实践。

避免使用unload事件

在任何浏览器中，优化 bfcache 最重要的方式就是：永远不要使用unload事件！

unload事件对于浏览器来说是有问题的，因为它早于 bfcache，并且互联网上许多页面都是在“触发unload事件后页面将不继续存在”的（合理）假设下运行的。这就带来了一个挑战，因为很多页面也是在假设“unload事件将在用户导航离开的时候触发”的情况下构建的，而这种情况已经（在很长一段时间^[5]）不再成立。

因此，浏览器面临着两难境地，他们得从中做出选择，它们能够改善用户体验，但也有破坏页面的风险。

Firefox 选择将添加了unload事件监听的网页认定为不符合 bfcache 条件，这样做风险较小，但也会使很多页面失去缓存资格。Safari 会尝试缓存带unload事件监听的网页，但为了减少破坏页面的风险，当用户离开时，它不会运行unload事件。

由于 Chome 中65% 的网页^[6]都注册了unload事件监听，为了能够尽可能多的缓存网页，Chrome 选择与 Safari 的实施方案保持一致。

用pagehide事件来代替unload事件。pagehide会在每次unload事件触发时被触发，并且在页面缓存到 bfcache 时也会触发。

事实上，Lighthouse v6.2.0^[7]添加了no-unload-listenersaudit，它会在页面的 Javascript（包括第三方库）添加了unload事件监听时给开发者发出警告。

警告：切勿添加 unload 事件监听器！请改用pagehide事件。添加 unload 事件侦听器将使您的网站在Firefox中加载变慢，并且该代码甚至大部分时间都不会在Chrome和Safari中运行。

条件性添加beforeunload事件监听

beforeunload事件不会让你的页面在 Chrome 和 Safari 浏览器中不符合 bfcache 条件，但是会让页面在 Firefox 中不符合 bfcache 条件，所以请避免使用该事件，除非必须使用时。

然而，与unload事件不同，beforeunload事件的使用是完全合理的。例如，当你想提醒用户离开页面会丢失未保存的更改。因此，在用户有未保存的改动时，添加beforeunload事件监听并在保存以后立刻移除，这种做法是值得推荐的。

尽量避免：

以上代码无条件添加了beforeunload事件监听。推荐做法：

以上代码在需要时添加beforeunload事件监听，并在不需要时移除。

避免使用 window.opener 引用

在某些浏览器（包括基于 Chromium 的浏览器）中，如果使用window.open()或（基于88版本之前的 Chromium^[8]）从带有target = _blank的链接中打开了页面，而未指定rel =" noopener"，则打开的页面将具有对打开页面窗口对象的引用。

除了存在安全风险^[9]之外，不能将带有非 nullwindow.opener引用的页面安全地放入 bfcache 中，因为这可能会给试图访问它的页面带来破坏。

因此，最好避免使用rel="noopener"来创建window.opener引用。如果你的站点需要打开一个窗口并通过window.postMessage()或直接引用该窗口对象进行控制，则打开的窗口和opener 均不符合 bfcache 的条件。

用户离开之前，关闭建立的连接

如上所述，将页面放入bfcache后，所有 JavaScript 的计划任务都将暂停，然后在从缓存取出页面时恢复执行。

如果这些 JavaScript 的计划任务只使用了 DOM API 和当前页面独立的 API，在用户看不见页面时暂停这些任务并不会造成问题。

但是，如果这些任务使用了可以被同源的其他页面访问的 API（例如：IndexedDB，Web Locks，WebSockets 等）就可能会出现问题，因为暂停这些任务可能会阻止其他选项卡中的代码运行 。

因此，在以下情况下，大多数浏览器将不会尝试将页面放入bfcache：

• 含有未完成IndexedDB 事务^[10]的页面
• 含有正在进行fetch()^[11]或XMLHttpRequest^[12]的页面
• 含有WebSocket^[13]链接或WebRTC^[14]连接的页面

如果你的页面正在使用这些 API 中的其中一个，最好总是在页面pagehide或freeze事件期间关闭连接并删除或断开观察者的连接。这样浏览器就可以安全地缓存页面，而不会影响其他打开的选项卡。

如果从 bfcache 还原了页面，你可以（在pageshow或者resume事件中） 重新打开或重新使用这些 API。

使用以上列出的 API 不会使页面失去存储在 bfcache 的资格，只要它们在用户离开之前没有在活动状态。但是，目前使用某些API（嵌入式插件，Workers，广播频道和一些其他API^[15]）确实会使页面无法缓存。尽管 Chrome 最初在 bfcache 的初始版本中有意保守一些，但长期目标是使 bfcache 兼容尽可能多的 API。

测试以确保你的页面可缓存

尽管无法确定页面在卸载时是否已放入缓存中，但是可以确定后退和前进导航时从缓存中恢复了页面。

目前在 Chrome 中，一个页面最多可以在 bfcache 中保留三分钟，这让我们有足够的时间（使用Puppeteer^[16]或WebDriver^[17]之类的工具）来运行测试以确保导航离开页面再点击“后退”按钮之后pageshow事件的persisted属性为true。

值得注意的是，正常情况下，页面应在缓存中保留足够长的时间以运行测试，但可以随时将其静默释放（例如当系统内存不足时）。测试失败并不一定意味着你的页面不可缓存，因此你需要配置测试或相应地建立失败标准。

在 Chrome 中，bfcache 当前仅在移动设备上启用。要在桌面上测试 bfcache，你需要启用 ＃back-forward-cache^[18]。

关闭 bfcache 的方法

如果你不希望将页面存储在 bfcache 中，可以通过将顶级页面响应中的Cache-Control标头设置为no-store来确保不缓存该页面：

所有其他缓存指令（包括子帧上的no-cache甚至no-store）都不会影响页面使用 bfcache 的资格。

尽管此方法有效且可在浏览器中使用，但它还是具有其他缓存和性能隐患。为了解决这个问题，有人建议添加一个更明确的关闭机制^[19]，包括在需要时清除 bfcache 的机制（例如，当用户注销共享设备上的网站时）。

另外，在 Chrome 中，目前可以通过＃back-forward-cache以及基于企业策略的关闭^[20]来进行用户级的关闭。

注意：鉴于 bfcache 提供了明显更好的用户体验，不建议你关闭，除非出于隐私原因绝对必要，比如当用户从共享设备上注销了网站。

bfcache 如何影响分析和性能衡量

如果使用分析工具跟踪对你网站的访问，你可能会发现报告的浏览量总数有所下降，因为 Chrome 持续为更多用户启用了 bfcache。

实际上，你可能已经低估了其他实现了 bfcache 的浏览器中的浏览量，因为大多数流行的分析库都不会将 bfcache 还原作为新的浏览量进行跟踪。

如果你不希望由于 Chrome 启用 bfcache 而导致浏览量下降，则可以通过监听pageshow事件并检查persisted属性来将 bfcache 恢复报告为浏览量（推荐）。

以下示例显示了如何使用 Google Analytics 进行此操作，其他分析工具的逻辑应类似：

性能测试

bfcache 也可能对真实场景中收集到的性能指标产生负面影响，特别是衡量页面加载时间的指标。

由于 bfcache 导航会还原现有页面而不是启动新页面加载，因此启用 bfcache 时，收集的页面加载总数将减少。尽管如此，（将页面重新加载改为）从 bfcache 加载的时间可能是数据集中最快的。因为根据定义，来回导航属于重复访问，并且（由于HTTP 缓存）重复页面的加载通常比第一次访问者的页面加载要快。

带来的结果是你的数据集中的快速加载完成的页面变少了，整体页面加载速度变慢了，尽管用户体验的性能可能得到了改善。

有几种方法可以解决此问题。一种是在所有页面加载指标中标记各自的导航类型^[21]：navigate，reload，back_forward或prerender。这将使你能够继续在这些导航类型中监视性能 - 即使总体分布偏慢。建议将这种方法用于不以用户为中心的页面加载指标，例如TTFB（Time to First Byte）。

对于像 Core Web Vitals 指标中以用户为中心的指标，更好的选择是报告一个更准确地表示真正用户体验的值。

注意：不要将 Navigation Timing API 中的 back_forward 导航类型与 bfcache 还原混淆。Navigation Timing API 仅能标记页面的加载，而从 bfcache 还原是属于之前导航页面的重复使用。

对 Core Web Vitals 指标的影响

Core Web Vitals指标用于衡量用户多维度的网页体验（加载速度，交互性，视觉稳定性），而且由于用户体验 bfcache 还原的速度比传统页面加载更快， Core Web Vitals 指标能反映这一点非常重要 。毕竟，用户不在乎是否启用了 bfcache，他们只是在乎导航的速度！

诸如Chrome 用户体验报告^[22]之类的工具，它可以收集和报告 Core Web Vitals 指标，将很快进行更新，届时会将 bfcache 还原视为单独的页面访问统计到数据集中。

尽管 bfcache 恢复后还没有专用的 Web 性能 API 来衡量这些指标，但是可以使用现有的 Web API 来估算它们的值。

• 对于LCP（Largest Contentful Paint），由于页面结构中的所有元素都将同时绘制，你可以使用pageshow事件的时间戳与下一个绘制的框架的时间戳的差值。请注意，bfcache 还原时，LCP 和 FCP 的值是相同的。
• 对于FID（First Input Delay），你可以在pageshow事件中重新添加（与FID polyfill^[23]所使用的监听相同的）事件监听，并将 bfcache 恢复后第一次交互的延迟时间上报为 FID。
• 对于CLS（Cumulative Layout Shift），你可以继续使用现有的 Performance Observer；你要做的就是将当前的 CLS 值重置为 0。

有关 bfcache 如何影响每个指标的更多详细信息，请参阅各个 Core Web Vitals指南页面。有关如何在代码中实现这些指标 bfcache 版本的特定示例，请参阅PR - adding them to the web-vitals JS library^[24]。

从 v1 开始，web-vitals^[25]JavaScript 库在其报告的指标中支持 bfcache 恢复^[26]。使用 v1 或更高版本的开发人员无需更新代码。

其他资料

• Firefox Caching^[27]（Firefox 浏览器的 bfcache）
• Page Cache^[28]（Safari 浏览器的 bfcache）
• Back/forward cache: web exposed behavior^[29]（不同浏览器中 bfcache 的差异）
• bfcache tester^[30]（测试不同的API和事件对浏览器bfcache的影响）

参考资料