谷歌 Chrome 及所有基于 Chromium 的浏览器（如 Edge、Vivaldi、Opera）即将迎来一项重大的性能升级：原生支持 <video> 和 <audio> 元素的懒加载（Lazy Loading）。
这一由独立开发者 Helmut Januschka 推动的功能，旨在解决长期以来网页媒体资源加载效率低下的痛点。预计该功能将在 Chrome 148 稳定版中默认启用，标志着网页媒体加载从“JavaScript hacks”时代正式迈入“原生标准化”时代。
什么是媒体懒加载？
懒加载（Lazy Loading） 是一种优化策略：浏览器不会在页面打开时立即加载所有资源，而是等到用户滚动到该资源即将进入视野（Viewport）时，才开始下载。
- 过去：仅支持
<img>（图片）和<iframe>（框架）。 - 现在：扩展至
<video>（视频）和<audio>（音频）。
工作原理对比
| 场景 | 无懒加载 (传统) | 开启懒加载 (loading="lazy") |
|---|---|---|
| 页面加载瞬间 | 浏览器立即下载页面上所有视频/音频文件，无论用户是否看得到。 | 浏览器跳过视口外的媒体文件，优先加载首屏内容。 |
| 用户滚动时 | 资源早已加载完毕（或正在排队阻塞其他资源）。 | 当用户滚动到视频附近时，浏览器即时触发下载。 |
| 用户未滚动到底部 | 底部视频依然被下载，浪费流量和带宽。 | 底部视频永远不会被加载，节省大量数据。 |
对 window.onload 影响 | 离屏媒体可能阻塞页面完全加载事件。 | 离屏媒体不阻塞，页面交互响应更快。 |
为什么需要“原生”支持？
在此之前，大多数网站为了实现视频懒加载，不得不依赖 JavaScript（通常使用 Intersection Observer API）。虽然有效，但存在明显缺陷：
- 无法利用预加载扫描器：浏览器的预加载扫描器（Preload Scanner）在解析 HTML 早期阶段就会发现资源。JS 方案执行较晚，错过了最佳的网络请求时机。
- 增加复杂性：开发者需要编写额外的代码来监听滚动、动态设置
src属性，容易出错且增加维护成本。 - 性能瓶颈：JS 执行本身消耗主线程资源，且在低端设备上可能导致加载延迟。
- 交互冲突：难以完美处理与
autoplay（自动播放）和preload（预加载）属性的复杂交互逻辑。
原生支持的优势：
“原生懒加载允许浏览器通过网络感知的阈值优化资源加载，正确处理与自动播放和 preload 属性的交互，并避免离屏媒体阻塞
window.onload事件。”
—— Helmut Januschka
开发者如何使用？
一旦该功能在稳定版上线，使用方法将变得极其简单，与图片懒加载完全一致。只需在 HTML 标签中添加 loading="lazy" 属性：
视频懒加载
<!-- 以前：需要复杂的 JS 监听 -->
<video loading="lazy" src="movie.mp4" controls></video>
音频懒加载
<!-- 以前：需要动态插入 source 标签 -->
<audio loading="lazy" src="podcast.mp3" controls></audio>
注意：
- 该属性仅对视口外的元素生效。
- 对于首屏可见的媒体，建议不要使用此属性，或使用
loading="eager"强制立即加载，以避免用户看到空白占位符。
发布时间表
根据 Chromium 的代码提交记录：
- 1 月：功能首次在 Chromium 代码库中实现。
- 2 月：功能落地并进行内部测试。
- 3 月底：进入发布流程（Release Channel）。
- 近期：新的更改列表（CL）已将该功能标记为在稳定版构建中默认启用。
- 预计版本：Chrome 148（及其他基于 Chromium 的浏览器对应版本）。
影响与意义
- 网页速度显著提升：对于包含多个视频的博客、新闻站或社交媒体，首屏加载时间（FCP/LCP）将大幅缩短。
- 节省用户流量：移动端用户不再为从未观看的视频浪费宝贵的数据流量。
- 降低服务器负载：网站托管商将减少大量的无效带宽消耗，直接降低运营成本。
- 标准化体验：统一了开发标准，消除了不同 JS 库实现带来的兼容性差异。
评论