你以为 iframe 里视频播，只能靠 visibilitychange 手动暂停？Chrome 155 今天把这件事彻底原生化了

你以为 iframe 里视频播，只能靠 visibilitychange 手动暂停？Chrome 155 今天把这件事彻底原生化了

写过前端的都踩过这个坑：页面上嵌了一个第三方视频 iframe，切换 tab 之后视频还在后台放，主线程被拖累得滚动都卡。

解决这个问题以前只有一条路：手动监听 visibilitychange，自己调 pause()。

// 旧方式：每个嵌了 video 的 iframe 都要写这套
document.addEventListener('visibilitychange', () => {
  if (document.hidden) {
    document.querySelectorAll('iframe').forEach(iframe => {
      const win = iframe.contentWindow;
      try {
        const video = win.document.querySelector('video, audio');
        video && video.pause();
      } catch (e) { /* 跨域 iframe 拿不到 */ }
    });
  }
});

而且这套代码还有很多问题：跨域 iframe 拿不到 DOM、每个页面都要手动写、不同浏览器行为不一致。

Chrome 155（2026-10-06 stable）把这个机制直接做进了浏览器的 Permission Policy 里。

Chrome 155 做了什么

Chrome 155 引入了一条 Permission Policy：当 iframe 从视口不可见时，浏览器自动暂停 iframe 内的音频和带声音的视频播放。

具体触发条件：

• 用户切换 tab，iframe 所在页面进入后台
• iframe 被 display: none 或 visibility: hidden 隐藏
• iframe 被其他内容完全遮挡

关键细节：

• muted 媒体不受影响，静默播放照常进行
• 不需要任何 JavaScript 代码，完全由浏览器在 Permission Policy 层面处理
• 跨域 iframe 同样适用，不需要跨域脚本

// Chrome 155 之后，这个逻辑彻底不需要了
// 浏览器自动在底层处理，开发者零成本

// 你甚至可以删掉之前写的 visibilitychange 监听
// 因为它做的事情浏览器现在帮你做了

性能收益有多大

在 Chrome 155 之前，一个嵌了视频的 background iframe 会：

1. 继续解码视频帧
2. 继续处理音频解码
3. 持续占用主线程（即使是 background 状态）
4. 阻止浏览器把该 iframe 所在进程挂起

Chrome 155 之后，当 iframe 不可见时，音频/视频解码完全暂停，iframe 进程可以真正进入休眠状态。

对于长列表页面嵌了多个第三方视频 iframe 的场景，这个改动对滚动流畅度的影响是直接可测的。

开发者行动项（下一步）

① 检查冗余代码

翻一下你的项目里有没有这种 visibilitychange + iframe + pause 的组合逻辑——Chrome 155 之后这段代码可以删了：

// 如果你的代码只是单纯暂停所有 iframe 媒体
// 现在可以直接删掉，因为浏览器自动处理
document.removeEventListener('visibilitychange', iframePauseHandler);

② 确认 muted 行为是否符合预期

如果你依赖 muted 视频继续在后台播放（比如某些数据采集场景），Chrome 155 的行为变更不会影响你—— muted 媒体不受此 Policy 影响。

③ 测试跨浏览器一致性

目前此机制仅在 Chrome 155+ 实现。Firefox 和 Safari 尚未跟进，建议在 Chrome 为主的产品环境中优先受益，但仍需保留对非 Chrome 用户的 fallback 逻辑。

Chrome 155 今天悄悄上了很多功能，但这个「iframe 媒体自动暂停」是唯一一个你不需要做任何事就能直接受益的性能优化。翻一下代码仓库吧——很可能你写的某段 visibilitychange 监听器，今天已经变成了一段可以删掉的死代码。