2019年，图片标签就有了loading="lazy"。但视频和音频一直没有。

如果你的网页下方放了视频，用户还没看到，视频就已经开始下载了。白白浪费流量，还拖慢页面速度。要解决这个问题，以前只能自己写IntersectionObserver，代码量不小。

现在好了。视频和音频的原生懒加载已经成为标准。Chrome 148（2026年5月7日）会默认开启这个功能。Firefox和WebKit也在开发中，很快就能用上。

用法和图片一样，加一个属性就行。

基本用法

最简单的写法：

<video src="intro.webm" loading="lazy"></video>

浏览器会推迟下载视频，直到它快出现在屏幕上（或者被Tab面板、轮播图切换出来的时候）。

如果你想同时放一张封面图：

<video src="intro.webm" poster="cover.jpg" loading="lazy"></video>

建议顺手加上width和height（或者用aspect-ratio）。视频如果没有尺寸，加载前不占空间，页面布局会突然跳动。懒加载的视频因为加载更晚，这个跳动会更明显。

三个需要注意的地方

1. 封面图也会被延迟

这可能是最让人意外的。加了loading="lazy"以后，浏览器不光延迟视频，连poster指定的封面图也不下载了。

仔细想想也对：视频都还没出现，封面图确实也没必要提前加载。但有一种情况：视频放在折叠面板里，你想让用户先看到封面图，点击后再播放视频。这时候封面图也跟着延迟就不合适了。

如果你希望封面图立刻显示，视频延后加载，有两个办法：

<!-- 方法一：poster不用lazy，改用CSS背景图 -->
<div class="video-wrapper" style="background-image: url('cover.jpg')">
  <video src="intro.webm" loading="lazy"></video>
</div>

<!-- 方法二：用preload="none"，不加lazy -->
<video src="intro.webm" poster="cover.jpg" preload="none"></video>

方法二少写了一个属性，但preload不等于lazy。它们的区别下面会讲到。

2. autoplay反而更好用了

以前，加了autoplay的视频在页面加载时就开始播放，不管它在不在屏幕上。一个放在页面底部的视频，用户还没滚到那里，就已经在后台播放了，浪费流量和CPU。

加了loading="lazy"以后，autoplay的行为被推迟了：视频要滚到屏幕附近才开始播放。这个行为写进了HTML规范。

<video
  src="background.webm"
  loading="lazy"
  autoplay
  muted
  playsinline
></video>

注意：muted和playsinline不是lazy的要求，是浏览器对autoplay本身的限制。大多数浏览器要求视频必须静音且内联播放才允许自动播放。不管有没有lazy，这两个属性都要带上。

3. preload加上lazy后行为有变化

preload本来就有点绕，加上loading="lazy"以后更绕了。

先回顾preload的三个值：

• auto（默认）：浏览器自己决定下载多少，有些浏览器会直接下载整个视频

• metadata：只下载一点点元数据，够显示时长和第一帧

• none：不下载任何视频数据

关键来了：当视频有loading="lazy"时，这些行为不会消失，而是被推迟到视频可见的时候才生效。也就是说，你设置preload="auto" + loading="lazy"，浏览器不会在页面加载时就下载视频，但等视频滚到屏幕附近时，它还是会按auto的逻辑来下载。

还有一个细节：preload="none"和loading="lazy"可以一起用。效果是视频数据完全不预加载，而且整个加载行为推迟到可见。如果你只想让封面图先出来，视频完全不预载，这个组合比单独用preload="none"更省带宽。

另外preload这个属性在不同浏览器里的实现本来就不太一致。lazy不会修复这些问题，只是把它们推迟了。

audio的特殊要求

audio的懒加载比video简单，不用管封面图和画面尺寸。但有一个容易忽略的地方：audio必须有controls属性，懒加载才能生效。

<!-- 有效：懒加载会生效 -->
<audio src="podcast.mp3" loading="lazy" controls></audio>

<!-- 无效：懒加载不会生效 -->
<audio src="podcast.mp3" loading="lazy"></audio>

原因很简单：懒加载的触发条件是元素可见且和屏幕有交集。audio没有控件就不可见，不可见就不会触发。video没有这个问题，因为视频本身就有画面占位。

至于autoplay，audio比video更严格。浏览器通常会阻止音频自动播放，除非用户已经和页面有过互动，或者给了网站专门权限。lazy不会绕过这些限制，但一旦autoplay被允许，行为和video一样：等到元素可见了才开始播放。

首屏视频不要用懒加载

这和图片的懒加载是同一个坑：如果视频在页面加载时就已经在屏幕上，加loading="lazy"反而会拖慢加载。

正常情况下，浏览器解析HTML时就会开始拉取视频。但loading="lazy"要求浏览器先等页面布局完成，判断元素是否可见，然后才开始请求。这个等待布局的时间，放在首屏元素上就是白费功夫，可能会拖低LCP（Largest Contentful Paint）。

所以记住：只有不在首屏的视频才需要加lazy。

浏览器支持情况

截至2026年4月：

• Chrome 148（5月7日发布）默认开启。147版可以通过命令行flag --enable-features=LazyLoadVideoAndAudio 提前体验

• Firefox和WebKit：Squarespace贡献了代码，正在审核中。Firefox的补丁在Phabricator（D278547），WebKit的PR在GitHub（#58220），暂时还没合并

特性检测一行代码就够了：

'loading' in HTMLMediaElement.prototype; // 返回true表示支持

HTMLMediaElement是video和audio共同的基类，所以这一行同时覆盖了两者。

不支持的浏览器会直接忽略loading="lazy"，不会报错，也不会影响正常播放。你可以放心用，不需要先做检测再决定要不要加。

最后

和手写IntersectionObserver相比，原生懒加载的优势就两个：不用写JS，autoplay的推迟行为是规范保证的。但手写方案能做更精细的控制（比如自定义触发距离、预加载策略），如果你的场景比较特殊，原生方案覆盖不了，手写IO还是可以继续用。

loading="lazy"对video和audio的支持，算是把2019年图片就有的能力补齐了。写法简单，降级安全，几个要注意的地方提前知道就行。等Firefox和WebKit都合并了，就可以彻底放心用了。

本文内容仅供个人学习、研究或参考使用，不构成任何形式的决策建议、专业指导或法律依据。未经授权，禁止任何单位或个人以商业售卖、虚假宣传、侵权传播等非学习研究目的使用本文内容。如需分享或转载，请保留原文来源信息，不得篡改、删减内容或侵犯相关权益。感谢您的理解与支持！

链接: https://fly63.com/article/detial/13682