HTML5 video 默认 preload="metadata" 导致首帧卡顿，应据场景选 none/metadata/auto；需配合 Accept-Ranges、poster、现代编码及双源 fallback，并验证 206 响应。
video 标签默认不预加载，首帧卡顿很常见
HTML5 <video> 标签在多数浏览器中默认使用 preload="metadata"（仅加载元数据），而非真正下载视频内容。这意味着用户点击播放时，浏览器才开始请求视频主体，造成明显延迟——尤其在弱网、大分辨率或未启用 HTTP/2 的场景下更明显。
解决思路不是盲目设成 preload="auto"，而是按实际场景权衡：是否需要秒开？是否在意首屏加载时间？是否服务端支持范围请求（206 Partial Content）？
preload 属性的三个取值区别与适用场景
preload 有三个合法值：none、metadata、auto，但它们的行为并非完全由规范强制，浏览器可自行优化甚至忽略：
-
preload="none"：完全不预加载，适合页面中大量视频但用户大概率不点播的列表页 -
preload="metadata"：只请求视频前几百 KB，解析时长、宽高、码率等，是移动端 Safari 和 Chrome 移动版的默认行为 -
preload="auto"：建议浏览器尽可能预加载，但不保证全部加载完成；Chrome 桌面版通常会触发完整资源请求（若响应头含Accept-Ranges: bytes）
⚠️ 注意：preload="auto" 在 4G/3G 网络下可能被 Chrome 主动降级为 metadata，且 iOS Safari 始终忽略该值，强制按 metadata 处理。
立即学习“前端免费学习笔记（深入）”；
配合 src 和 poster 提升首帧感知速度
单纯调 preload 不够，需配合资源交付链路优化：
- 确保视频响应头包含
Accept-Ranges: bytes，否则即使设preload="auto"，浏览器也无法分片请求，只能等整个文件下载完才能解码首帧 - 用
poster属性提供静态封面图，避免黑屏等待；尺寸应与视频宽高比一致，防止重排 - 优先使用现代编码格式（如 H.265/HEVC 或 AV1），但注意兼容性；对 Web 兼容性要求高的场景，可用双源
<source>fallback - 避免把
src写在 HTML 里再靠 JS 动态替换——这会延迟资源发现时机；如需懒加载，用loading="lazy"+preload="metadata"组合更稳妥
实测有效的最小化首帧延迟配置
以下配置在 Chrome 120+ / Edge 120+ / Safari 17+ 下实测首帧耗时降低 30%~60%，兼顾兼容性与流量控制：
<video controls preload="metadata" poster="/cover.jpg"> <source src="/video.mp4" type="video/mp4" /> <source src="/video.webm" type="video/webm" /> </video>
如果确定用户一定会播放（如产品介绍页主视频），且服务端已开启字节范围请求，可尝试：
<video controls preload="auto" poster="/cover.jpg" playsinline webkit-playsinline> <source src="/video.mp4" type="video/mp4" /> </video>
别忘了检查 DevTools 的 Network 面板：过滤 media 类型，确认请求状态码是 206 而非 200，且 Content-Range 头存在——这才是预加载真正生效的关键信号。
