浏览器窗口最小化后，定时器精度会降到多少？-js教程-PHP中文网

浏览器最小化后定时器变慢是因后台节流策略所致，chrome/edge等将setinterval/settimeout最小间隔强制拉长至约1000ms（长期后台可达4000ms），firefox和safari也类似；这是为降功耗、减cpu占用的标准行为，非bug。

浏览器窗口最小化后，定时器精度会降到多少？

浏览器窗口最小化后，定时器（如 setTimeout 和 setInterval）的精度会显著下降，通常被限制在约 1000ms（1秒）左右，即最小间隔不能短于 1 秒。

这是浏览器出于性能和功耗考虑主动实施的节流策略，并非 bug，而是标准行为（符合 HTML 规范）。

仿UC浏览器官方网站全屏jQuery幻灯片

下载

为什么最小化后定时器变慢？

浏览器会将后台标签页或最小化窗口的 JavaScript 执行优先级大幅降低；
目的是减少 CPU 占用、延长笔记本续航、避免干扰用户前台任务；
Chrome、Edge、Firefox 等主流浏览器均采用类似策略（规范中称“后台页面节流”）；
即使代码中设了 setInterval(fn, 10)，实际执行间隔可能变成 1000ms 或更长（尤其在长时间后台运行后可能进一步放宽到 4s+）。

不同浏览器的典型节流阈值

Chrome / Edge（基于 Chromium）：
- 标签页不可见（含最小化）时，setTimeout/setInterval 最小间隔 ≈ 1000ms；
- 若页面持续后台超过 5 分钟，可能进一步降为 4000ms（4秒）；
Firefox：
- 后台节流起始阈值也是 1000ms，但对长期后台更保守，可能更快进入更深节流；
Safari（macOS/iOS）：
- 同样限制在 1000ms 左右，且对 WebKit 进程整体调度更激进，有时恢复前台后需数秒才能恢复正常精度。

哪些定时器不受影响？

Web Workers 中的定时器：
- 在独立线程中运行，不直接受页面可见性影响（但若整个浏览器进程被系统挂起，仍可能延迟）；
requestIdleCallback：
- 不是定时器，但适合后台轻量任务，会在浏览器空闲时调用（最小化后仍可能触发，但时机不确定）；
Service Worker 中的定时逻辑（如 setTimeout）：
- 仅在 SW 激活且有事件触发时运行，本身不支持长期后台定时，不能替代页面定时器。

⚠️ 注意：performance.now() 和 Date.now() 的时间读取本身仍精确，只是你无法靠 setTimeout 驱动高频回调。

如何应对最小化导致的定时不准？

如果业务依赖高精度倒计时（如音视频同步、实时协作），不要依赖页面级 setTimeout/setInterval；
改用「时间戳校准法」：
- 记录开始时间（startTime = Date.now()）；
- 每次回调中计算已过去时间（elapsed = Date.now() - startTime）；
- 基于 elapsed 推算当前应处的状态，而非依赖调用次数；

对于心跳、保活类任务，可结合 visibilitychange 事件监听页面显隐：

document.addEventListener('visibilitychange', () => {
  if (document.hidden) {
    console.log('页面进入后台，暂停高频逻辑');
  } else {
    console.log('页面回到前台，重置定时器或校准状态');
  }
});

需要唤醒能力的场景（如闹钟、提醒），应使用 Push API + Notification，而非前端轮询。

不复杂但容易忽略。