首选preload="metadata"，它仅加载视频头信息（时长、宽高、封面帧等），兼顾首屏lcp性能与控件正常显示；preload="auto"在移动端常被降级，preload="none"需配合intersectionobserver手动load()。
video 的 preload 属性怎么选才不拖慢首屏
preload 不是“开/关”开关，而是加载粒度控制。设了 autoplay 时，preload 基本被忽略；没设时，它才真正起作用。
常见错误是把所有视频都写成 preload="auto"，结果首屏 LCP 直接被大视频拖垮——尤其在 3G 或低端 Android 上。
-
none：适合用户大概率不点播的视频（如页面底部“相关推荐”里的备用资源） -
metadata：首屏可见视频的默认选择。只拉头部信息（时长、宽高、编码），足够渲染控件和poster，延迟低、带宽省 -
auto：仅适用于 ≤2MB 的小体积视频（比如 banner 动画、图标解说），且要确认目标用户带宽稳定；Safari 会悄悄降级为metadata，别依赖它真能预加载全部
video 标签加 loading="lazy" 为什么没反应
因为 loading="lazy" 对 <video></video> 完全无效。它是 <img> 和 <iframe></iframe> 的原生属性，浏览器遇到 <video loading="lazy"></video> 会直接忽略，不报错也不懒加载。
想实现视频懒加载，必须手动控制：
- 初始状态用
data-src存真实地址，src留空或指向占位帧 - 用
IntersectionObserver监听进入视口（注意兼容性：旧版 Safari 需 fallback 到 scroll + getBoundingClientRect） - 触发后赋值
video.src = video.dataset.src，再调用video.load()启动加载
别漏掉 load() —— 否则有些浏览器不会开始请求资源。
poster 图片和 source 标签的加载优先级谁更高
poster 是视觉第一响应，<source></source> 是格式协商层，二者不冲突，但加载策略上必须分清主次。
poster 必须像 <img> 一样优化：压缩到 50KB 以内、指定 width/height 避免 layout shift、用 srcset 适配 DPR。如果它本身加载慢，LCP 就卡在这儿，后面再快也没用。
<source></source> 的顺序决定浏览器选用逻辑：
- 把兼容性好、解码快、体积小的格式放前面（例如 MP4 通常比 WebM 更稳妥，尽管 WebM 更小，但 Safari 对 WebM 支持晚，放前面可能 fallback 失败）
- 不要只按“先进程度”排，要按“实际覆盖用户比例 + 解码性能”排
移动端 video 布局自适应的坑在哪
视频容器宽度设成 100% 不等于响应式——关键在 aspect-ratio 和父容器约束。
常见问题：
- 没设
max-width: 100%，导致横屏手机里视频溢出 - 没用
aspect-ratio: 16 / 9（或对应比例），纯靠height: auto在某些安卓 WebView 下失效，高度塌陷 - 父容器用了
flex但没设flex-shrink: 0，小屏下被压缩变形
最简健壮写法：
<div class="video-wrapper"> <video controls poster="cover.jpg" preload="metadata"><source src="vid.mp4" type="video/mp4"></source></video> </div>
CSS：
.video-wrapper {
width: 100%;
aspect-ratio: 16 / 9;
}
.video-wrapper video {
width: 100%;
height: 100%;
display: block;
}
注意：aspect-ratio 在 iOS Safari 15.4+ 才完全可靠，老版本需用 padding-bottom hack 或 JS 补偿。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
