根本原因是资源体积、加载时机与网络调度不合理；优化重点在于“何时加载、如何加载、加载什么”，而非标签写法本身。
HTML 多媒体资源（<img>、<video></video>、<audio></audio>）加载慢，根本原因不是标签本身，而是资源体积、加载时机和网络调度策略不合理。优化重点不在“怎么写标签”，而在“什么时候加载、怎么加载、加载什么”。
图片用 loading="lazy" 但别滥用
现代浏览器原生支持 loading="lazy"，对非首屏 <img> 和 <iframe></iframe> 生效，能显著减少初始请求量。但它只对滚动触达区域前的资源起作用，且在 Safari 中对 <picture></picture> 支持不一致。
- 首屏关键图（如 banner、logo）必须移除
loading="lazy"，否则可能触发 FOUC 或白屏 -
<img src="..." loading="lazy" decoding="async">配合decoding="async"可避免解码阻塞主线程 - 服务端渲染（SSR）页面中，若首屏图被 SSR 渲染但实际未进入视口，仍建议保留 lazy —— 浏览器会自动忽略已渲染图的懒加载逻辑
<video></video> 默认不预加载，按需设置 preload
<video></video> 的 preload 属性控制浏览器是否提前获取媒体数据，默认值是 metadata（只拉取时长、尺寸等元信息），不是 auto。盲目设成 auto 会导致首屏带宽暴涨，尤其在移动端。
- 用户明确要播放的场景（如教程页、产品演示页）：设
preload="auto"，并配合poster提供首帧占位图 - 仅作装饰或次要内容（如背景视频）：设
preload="none"，用 JS 监听scroll或intersectionObserver触发加载 - 注意：Chrome 对
preload="auto"在后台标签页中会降级为metadata，iOS Safari 则始终忽略preload，强制按需加载
用 <source></source> + type 显式声明格式，避免 406 错误和重复请求
当 <video></video> 或 <audio></audio> 包含多个 <source></source> 时，浏览器会按顺序尝试请求，直到找到能解码的格式。但如果服务器未正确返回 Content-Type（比如 MP4 返回 text/plain），就会触发 HTTP 406 Not Acceptable，然后跳过该 source 继续试下一个 —— 这个过程不可见但耗时。
- 每个
<source></source>必须带type属性，例如<source src="clip.webm" type="video/webm"></source> - 确保 Web 服务器对每种扩展名返回正确的 MIME 类型（
video/mp4 → video/mp4，不是application/octet-stream） - 不要把高码率和低码率文件混在同一
<source></source>列表里——浏览器不会做自适应切换，那是 JavaScript 或 HLS/DASH 的事
字体和 SVG 图标优先走 font-display: swap 和内联
字体和 SVG 虽不算传统“多媒体”，但它们的加载阻塞渲染（尤其是 @font-face），且常被忽视。WebFont 加载失败时默认隐藏文本，造成空白或布局抖动。
- CSS 中定义字体时加
font-display: swap，让文本先用系统字体显示，字体加载完再替换，避免 FOIT（Flash of Invisible Text） - 小图标 SVG 直接内联到 HTML（
<svg>...</svg>），绕过 HTTP 请求；大图标用<img src="icon.svg">并开启 CDN 缓存 - 避免在 CSS 中用
url(data:...)内联大 SVG，Base64 编码后体积膨胀 ~33%，且无法单独缓存
真正卡顿的从来不是标签写法，而是资源决策——哪些该立刻加载、哪些可延迟、哪些该降质、哪些必须校验 MIME 类型。这些判断没法靠一个属性解决，得结合监控（如 LCP、INP）、真实设备测试和服务器配置一起调。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
