Chrome把视频延迟加载藏了6年，这次真敢动真格了

2019年，Chrome给图片和iframe（内嵌框架）加上了懒加载——用户滚动到附近才开始加载，页面打开速度肉眼可见地变快。但视频和音频标签里的多媒体内容，Chrome愣是晾了6年没管。

Google现在宣布，Chrome 148版本要把这块补丁打上。桌面端和移动端同步更新，代码直接进Chromium（开源浏览器核心）仓库，Edge这些"换皮浏览器"也会跟着喝汤。

为什么偏偏是第6年才动手

视频音频标签在现代网页里确实不如图片常见。大多数站点要么用YouTube/ Vimeo外链，要么上H5播放器，原生video/audio标签反而成了"遗老遗少"。

但遗老也有遗老的麻烦。比如新闻站点的视频摘要、播客平台的内嵌音频，这些场景下标签是轻量方案，却拖着整页加载速度。Google的测试数据显示，部分页面因视频预加载多耗了30%的首屏时间。

技术债就是这样。2019年解决80%的问题，剩下20%因为"不够疼"被无限期搁置，直到某次性能审计翻出来。

懒加载到底省了什么

原理像餐厅上菜：先给前菜（文字、布局），主菜（视频）等客人眼神飘过来再端。对带宽敏感的用户——地铁通勤、偏远地区、国际漫游——这意味着少付流量费。

更隐蔽的好处是电池。视频解码是耗电大户，延迟加载等于减少无效运算。Chrome团队没公布具体数字，但参考2019年图片懒加载的数据：某些页面加载时间从3秒压到1.5秒，数据用量砍掉一半。

这次扩展的逻辑完全一致：用户没看到的视频，就当它不存在。

开发者要改什么

好消息是大概率不用改。Chrome的懒加载默认开启，只要标签本身带loading="lazy"属性，或者浏览器判断元素在视口外足够远。

但有个细节：自动播放的视频可能被策略拦截。Chrome对自动播放的限制本来就严——静音才能自动播，用户交互后才能有声。懒加载叠加这层规则，意味着"滚动到+点击"双重触发，部分旧站点需要检查交互链路。

Edge、Opera、Brave等Chromium系浏览器会陆续跟进，时间表看各自维护团队的合并速度。Safari和Firefox（火狐）不在此列，它们走自己的渲染引擎路线。

6年时间，足够一个前端框架从爆红到过气。Google这次补票，是终于想起角落里那批原生标签用户，还是被Core Web Vitals（核心网页指标）的考核压力逼的？