后台标签页可能会对浏览器性能产生明显的负面影响，尤其是对电池续航时间。为了缓解此问题，过去几年来，Chrome 对后台标签页施加了各种限制。近期，开发者们付出了很多努力，可以做出进一步改进。本文档简要介绍了 Chrome 政策。本文档重点介绍了 Chrome 57 中的当前政策。 如需查看长期策略和后续计划，请参阅此文档。
针对后台优化应用
Web 开发者应注意，用户经常会在后台打开大量标签页，这可能会严重影响耗电量和电池续航时间。应尽量减少后台工作，除非这是提供特定用户体验的绝对必要条件。您应使用网页可见性 API 来检测网页何时在后台运行，并暂停所有不必要的工作（例如视觉更新）。
对于某些网站，这种简单的优化可以减少高达 75% 的 CPU 使用量：
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）的应用，以避免因超时关闭这些连接。在这些情况下，仍然应用运行计时器一次规则。
请注意，他的机制使用实际用时，而不是 CPU 时间。它非常接近 CPU 时间，并且可通过降低长时间阻塞主线程进行惩罚。
最后请注意，如果您在后台使用耗时较长的任务，您的应用可能会在很长一段时间（最长为任务时长的 100 倍）内受到限制。根据性能准则，将工作拆分为多个时长为 50 毫秒或更短的块，并使用 visibilityChange 监听器以避免在后台执行不必要的工作。
拒绝联系
Chrome 为运行测试套件和其他由用户批准的密集型计算等用例提供了 --disable-background-timer-throttling 标志。