preload属性是视频加载策略选择，取值none（不预加载）、metadata（仅元数据）、auto（尽可能加载），需依场景权衡；影响fcp、带宽、内存及体验，推荐banner用auto、教程用metadata、列表用none并结合视口监听动态调整。
preload 属性直接影响视频资源的初始加载行为，进而显著影响页面加载速度、带宽消耗和用户交互响应。它不是“开/关”式开关，而是一个策略选择，需结合使用场景权衡。
preload 的三个取值及实际行为差异
浏览器对 preload 的实现虽有规范约束，但存在厂商差异和运行时调整：
-
preload="none"：不主动请求视频文件，仅解析 HTML 后建立媒体元素对象。首次播放或调用
load()时才发起网络请求。适合低优先级视频（如页面底部的背景视频）或明确按需加载的场景。 -
preload="metadata"：只下载视频头部（含时长、尺寸、码率、关键帧索引等元数据），通常几 KB～几十 KB。可支持显示封面、准确控制进度条、响应
canplay事件。多数移动端浏览器默认采用此策略以节省流量。 -
preload="auto"：允许浏览器下载尽可能多的内容（可能包括首段视频帧甚至整个文件）。桌面端 Chrome/Firefox 常会预加载前几秒；Safari 可能更保守。注意：该值不强制全部加载，也不保证缓冲长度，且在移动网络下常被忽略或降级为
metadata。
性能影响的关键维度
影响不止于“快或慢”，需从多角度评估：
-
首屏渲染时间（FCP）：设为
auto可能触发大体积资源并行下载，阻塞关键 CSS/JS 解析，尤其在弱网或高并发请求时拉长 FCP。 -
初始页面大小与带宽占用：未设置或设为
auto时，视频资源计入 Lighthouse 的“未优化内容”项，增加 TTFB 和总传输量；none可将视频完全排除在初始加载路径外。 -
内存与解码压力：即使未播放，
auto下部分浏览器可能提前解码已缓存的帧，增加内存占用（尤其多视频页），在低端设备上易引发卡顿或崩溃。 -
用户体验一致性：设为
metadata能确保封面图及时显示、时长可读、播放按钮可点击，避免“点击无反应”的挫败感；而none需额外处理 loading 状态，否则用户可能误以为视频不可用。
推荐实践与适配建议
没有全局最优解，应依据视频类型、用户预期和上下文环境动态决策：
- 自动播放的首页 Banner 视频：设
preload="auto"，并配合muted和autoplay，提升首帧可见性；同时启用poster属性提供视觉占位。 - 用户主动触发的教程类视频：优先
preload="metadata"，兼顾快速响应与低开销；监听loadedmetadata后再展示播放控件。 - 列表页中多个缩略视频（如 TikTok 式流）：统一设
preload="none"，并在元素进入视口时通过 IntersectionObserver 动态切换为metadata或auto。 - 对移动用户或检测到 3G/4G 网络时，可通过
navigator.connection.effectiveType降级 preload 策略（例如从auto改为metadata），需搭配onloadstart监听验证生效情况。
补充说明：与 loading 和 fetchpriority 的协同
HTML5 视频暂不支持 loading="lazy"（仅 img 和 iframe 支持），但可通过 JS 实现懒加载逻辑；fetchpriority="low" 对 video 元素无效，浏览器忽略该属性。真正可控的加载优先级仍依赖 preload + 资源位置（如是否在首屏）+ 是否静音/自动播放等组合策略。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
