后台标签页可能会对浏览器性能产生显著的负面影响，尤其是对电池续航时间。为此，Chrome 在过去几年一直对后台标签页施加各种限制。我们最近做了很多工作来进一步改进，本文档概要介绍了 Chrome 政策。本文档重点介绍 Chrome 57 中的当前政策。 如需了解长期策略和后续计划，请参阅此文档。
针对后台优化应用
Web 开发者应注意，用户通常会在后台打开许多标签页，这可能会严重影响功耗和电池续航时间。除非为了提供特定的用户体验，否则应尽量减少后台工作。Page visibility API 应当用于检测网页何时在后台运行，并暂停所有不必要的工作，例如视觉更新。
对于某些网站，此简单优化可将 CPU 使用量最多减少 75%：
var doVisualUpdates = true;
document.addEventListener('visibilitychange', function(){
doVisualUpdates = !document.hidden;
});
function update() {
if (!doVisualUpdates) {
return;
}
doStuff();
}
政策
requestAnimationFrame()
根据文档，当网页在后台运行时，Chrome 不会调用 requestAnimationFrame()。这种行为从 2011 年就开始实施。
后台计时器对齐
从 Chrome 11 开始，每个独立计时器每秒最多运行一次。Chrome 会每秒批量运行一次这些计时器，以确保将进程唤醒次数保持在最低限度。播放有声音频的网页会被视为用户可见，且不受后台计时器限制。豁免会在音频停止播放几秒钟后持续几秒钟，以允许应用将下一个音轨加入队列。
请注意，当且仅当 Chrome 显示音频图标时，音频才会被视为可听。 静音音频流不符合豁免条件。
基于预算的后台计时器节流
在 Chrome 57 中提供的基于预算的计时器节流是计时器对齐机制的进一步扩展，可对后台计时器 CPU 使用情况施加额外限制。其运作方式如下：
- 每个后台标签页都有一个用于在后台运行计时器的时间预算（以秒为单位）。
- 页面在后台运行 10 秒后，将受到时间预算限制。
- 只有在时间预算为非负数时，才允许运行计时器任务。
- 计时器执行完毕后，系统会从预算中扣除其运行时间。
- 预算会随时间的推移而不断再生成（目前设置为每秒 0.01 秒的速率）。请注意，随着 Chrome 收集有关节流行为的更多数据，此预算再生率可能会调整。
这种限制会实现多种自动豁免：
- 播放音频的应用会被视为前台应用，不会受到节流限制。
- 具有实时连接的应用（WebSocket 和 WebRTC），避免因超时而关闭这些连接。在这些情况下，仍然应用 run-timers-a-second 规则。
请注意，此机制使用的是壁挂式时间，而不是 CPU 时间。它是对 CPU 时间的良好近似值，并会对长时间阻塞主线程进行惩罚。
最后，请记住，如果您在后台使用长时间运行的任务，您的应用可能会在很长一段时间（最长为任务持续时间的 100 倍）内被限制。根据性能指南，将工作拆分为每个耗时不超过 50 毫秒的多个块，并使用 visibilityChange 监听器来避免在后台执行不必要的工作。
选择停用
Chrome 提供了 --disable-background-timer-throttling 标志，适用于运行测试套件和其他用户批准的重型计算等用例。