Chrome把视频加载拖了3年，开发者终于不用写补丁了

网页里塞5个视频，首屏加载时间从4.2秒掉到1.8秒——这不是某个前端框架的优化案例，是Chrome浏览器原生支持的最新功能。Google上周确认，loading="lazy"属性正式覆盖和标签，开发者不用再为媒体懒加载写一行JavaScript。

三年前就该有的功能，为什么现在才给

图片懒加载2019年就进了Chrome，iframe跟进也不算晚。但视频和音频的懒加载，开发者等了整整三年。

问题卡在复杂度上。图片是静态资源，加载时机好算；视频带自动播放、预加载、缓冲策略，还要处理编解码器协商。Google Chromium团队的工程师在邮件列表里提过早期顾虑：粗暴延迟加载可能让自动播放视频"哑火"，用户滑到眼前了还在转圈。

所以过去三年，前端工程师被迫写"补丁"。用Intersection Observer API监听元素位置，算视口距离，动态改src属性。一个基础功能，人均重复造轮子。

某电商网站的技术负责人算过账：他们的商品详情页平均嵌入3.2个视频，懒加载脚本占页面JS体积的18%，还要维护两套逻辑——桌面端和移动端的触发阈值完全不同。

原生实现到底强在哪

新API的核心变化是把决策权交给浏览器引擎。声明式写法让Chrome自己决定"什么时候算近"，而不是开发者硬编码像素值。

具体差异体现在三个层面：

网络感知阈值。Chrome会根据连接速度调整预加载距离，4G下提前400像素开始加载，慢网可能缩到100像素。脚本做不到这种动态适配。

与现有属性的兼容。autoplay、preload、poster这些属性原本互相牵制，现在由浏览器统一协调优先级。offscreen视频不再阻塞window.onload事件，这是手动实现最难绕过的坑——很多开发者不知道视频缓冲会拖慢整页交互就绪时间。

代码瘦身。去掉懒加载脚本后，某内容平台的测试页面JS体积下降23%，Lighthouse性能评分从72涨到89。

WebKit和Firefox的态度也值得注意。苹果工程师在WebKit bug追踪器里标记了相关议题，Mozilla的实现进度稍慢，但标准草案已在WHATWG讨论。这意味着loading="lazy"可能成为跨浏览器的默认实践，就像当年的图片懒加载一样。

谁最该立刻用起来

内容型网站是首要受益者。新闻站点、博客、知识库——这类页面视频密度高，但用户滚动深度差异大。首屏外的视频，70%可能根本不会被看到，却一直在后台抢带宽。

电商详情页次之。产品视频、360度展示、用户评价录像，堆在一起是性能灾难。某头部平台的A/B测试显示，视频懒加载让移动端跳出率下降11%，因为首屏渲染快了，用户没被白屏劝退。

但有一个场景要慎用：短视频信息流。如果用户预期是"下滑即播"，原生懒加载的保守阈值可能造成感知延迟。这时候还是需要自定义脚本，把触发距离调得更激进。

Google的部署时间表已经明确：Chrome 135稳定版全量推送，136版本优化阈值算法，137加入开发者工具的可视化调试。对于还在用旧版脚本的项目，迁移成本很低——删掉JS，加个属性，测试一遍。

一个细节：Chromium的代码提交记录显示，这项功能在Blink>Media组件下的追踪ID是loading-lazy-media，去年Q3完成原型，Q4通过安全评审，今年1月进Beta。这个节奏比多数新API快，说明Google内部也承认"欠账太久"。

前端圈子有个老梗：最好的代码是删掉的代码。这次更新让多少人的懒加载工具库可以归档了？