preload属性影响首屏速度与流量消耗，取值none（不预加载）、metadata（仅元数据）、auto（浏览器自主决定，移动端常降级）；慎用auto，优先组合poster、decoding="async"、范围请求等优化手段。
HTML5 的 preload 属性看似简单，实则直接影响页面首屏加载速度、带宽消耗和用户体验——用得合适能提升媒体就绪速度，用得冒进反而拖慢页面渲染、浪费用户流量。
preload 的三个取值及其真实影响
none：完全不预加载，媒体资源直到用户主动播放（或 JS 调用 load()）才开始获取。适合非首屏、低优先级或大体积媒体（如长视频、高清音频），尤其对移动端用户或弱网环境更友好。
metadata：仅获取元数据（时长、尺寸、封面帧、音轨信息等），不下载主体内容。适用于需要显示播放器控件（如进度条长度）、封面图或做格式兼容判断的场景，开销小、响应快。
auto：浏览器可自主决定是否预加载全部内容。注意：它不是强制指令，现代浏览器（尤其是 Chrome 和 Safari）在移动设备上通常会忽略 auto，降级为 metadata 或 none 以节省资源；桌面端也可能根据内存、网络类型（如检测到“Save-Data”标头）动态调整。
立即学习“前端免费学习笔记（深入）”；
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
何时该用 preload="auto"？谨慎再谨慎
真正适合 auto 的场景极少，需同时满足：
- 媒体是核心内容（如产品介绍页的主宣传视频）
- 文件体积可控（建议 ≤ 2MB，H.264 + AAC 封装）
- 用户大概率会播放（例如页面自动滚动到视口后 1–2 秒内触发播放）
- 已通过
loading="lazy"或 IntersectionObserver 延迟加载非首屏媒体，避免初始请求洪峰
否则，auto 很可能提前占用 HTTP 连接、挤占关键资源（CSS/JS/首屏图片）的带宽，导致 LCP（最大内容绘制）延迟。
比 preload 更有效的性能控制手段
单纯依赖 preload 是被动策略。更推荐组合使用：
- 用
poster属性提供静态封面图，替代首帧解码，减少初始视频解码开销 - 对
<video>添加decoding="async"，让浏览器在后台线程解码，避免阻塞主线程渲染 - 服务端开启范围请求（
Accept-Ranges: bytes）和合理缓存头（Cache-Control: public, max-age=31536000），让浏览器可分片加载、复用已缓存片段 - 关键媒体启用
fetchpriority="high"（Chrome 109+），提示浏览器提升其网络请求优先级
移动端与第三方嵌入的特殊注意事项
iOS Safari 对 preload 支持有限：即使设为 auto，也默认只加载元数据；且所有视频默认静音（muted）才能自动播放。安卓 WebView 行为更碎片化，部分版本忽略 preload。
嵌入 YouTube/Vimeo 等 iframe 视频时，preload 属性完全无效——它们由自身播放器控制加载逻辑。此时应改用懒加载 iframe（如 loading="lazy"）、延迟注入 src，或使用轻量封面图 + 点击后动态创建 iframe 的方式。
