Page Visibility API 使用指南优化网页后台资源消耗

HTML中如何使用Page Visibility API节省后台资源

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

能省吗？答案是肯定的，但有个关键前提：它只在你主动响应 visibilitychange 事件时才生效。浏览器可不会那么“贴心”，自动帮你停掉那些后台的 setInterval、requestAnimationFrame 或是网络请求——这些资源清理工作，都得开发者自己动手。

监听 visibilitychange 事件要兼容旧版浏览器

说起来，这个API的标准化之路还有点小波折。早期的Chrome、IE和Firefox都曾使用带前缀的事件名，比如 webkitvisibilitychange、msvisibilitychange。好在现代浏览器已经统一支持标准事件名 visibilitychange。不过，如果你的项目还需要顾及IE10或Android 4.4 WebView这类“老前辈”，那就得做点兼容处理了：

• 首先，检查 document.hidden 属性是否存在，如果不存在，基本可以判定浏览器不支持，直接跳过即可。
• 接着，可以用一个小技巧来探测当前可用的前缀：['', 'webkit', 'ms', 'moz'].find(prefix => (prefix + 'Hidden') in document)。
• 注册事件时，使用动态拼接的事件名：document.addEventListener(prefix + 'visibilitychange', handler)。
• 值得注意的是，Safari 13.1+ 以及所有现代版本的 Chrome、Firefox、Edge 都已完全支持无前缀版本，直接使用 visibilitychange 就行。

document.visibilityState === 'hidden' 时该停哪些东西

当然，也不是所有后台行为都需要“一刀切”地暂停。我们的核心目标，是盯住那些“用户看不见却还在后台高频执行”的逻辑。哪些是重点目标呢？

• setInterval / setTimeout 轮询：比如每3秒拉取一次新消息的 fetch 请求。这类定时器必须用 clearInterval 清理，否则CPU占用会持续存在。
• requestAnimationFrame 动画循环：无论是Canvas动画还是CSS动画，只要涉及持续渲染，就必须配对调用 cancelAnimationFrame 来停止。
• 视频/音频播放：调用 video.pause() 暂停即可。但要避免直接重置 video.currentTime = 0，否则用户的播放进度就丢失了。
• WebGL渲染帧：停掉 render() 函数的调用，GPU的占用率会立刻降下来。
• 非关键日志或埋点上报：这类请求可以暂时攒在一个数组里，等页面状态恢复为 visible 时，再批量发送出去，能有效减少零碎的网络小包。

容易忽略的边界情况和坑

原理看似简单，但在实际线上环境中，稍不留神就容易踩坑。下面这些情况，值得你多看一眼：

立即学习“前端免费学习笔记（深入）”；

• visibilitychange 事件不保证实时：如果用户快速切换两次浏览器标签页，事件可能会被浏览器合并或延迟几毫秒触发。因此，不能依赖它来做精确的计时逻辑。
• document.hidden 是只读属性：试图将它设为 true 来模拟隐藏状态是无效的，也别用这种方式来测试你的暂停逻辑。
• hidden 状态不等于页面卸载：真正表示“页面即将离开”的事件是 pagehide 或 beforeunload。而 visibilitychange 只管“页面是否可见”这一件事。
• WebView环境需谨慎：在微信内嵌页、Android App内置WebView等场景下，需要确认宿主环境是否启用了Page Visibility API支持。部分老版本WebView可能始终返回 visible。
• 暂停后恢复时，需防重复启动：页面重新可见时，别急着盲目重启所有定时器。先检查一下它们是否已经被手动清除，避免造成重复启动，导致逻辑错乱。

话说回来，最容易被漏掉的往往是那些视觉密集型操作：轮播图、粒子动画、实时图表的重绘……它们在后台运行时，用户可能感觉不到界面卡顿，但内存和GPU的消耗却是真实存在的，一不留神就可能多占用30%的内存。所以，一个实用的经验法则是：只要页面中存在持续运行的Ja vaScript逻辑，就值得考虑加一层 visibilityState 的判断。这不仅是优化，更是一种对用户设备资源的负责态度。