poster加载慢主因是浏览器加载策略与资源调度失当，而非图片体积大；需动态注入、配合IntersectionObserver、preload="metadata"及load()刷新等主动管理措施。
为什么 poster 加载慢不是“图太大”这么简单
poster 图片加载慢，常被归因为体积大，但真实瓶颈往往在浏览器加载策略和资源调度上。比如 Safari 在未设 preload="metadata" 时，压根不发请求；又或者写死的 poster="cover.jpg" 被解析阶段立即触发下载，哪怕视频还在折叠区、用户根本没滚动过去。这不是图片本身的问题，而是你把 poster 当成了静态装饰，没把它当作一个需要主动管理的资源状态。
动态注入 + IntersectionObserver 是最可控的起点
避免 HTML 中硬编码 poster 属性，改用 JS 按需注入：
- 用
IntersectionObserver监听视频进入视口后再调videoEl.setAttribute('poster', 'thumb-720p.webp') - 对默认不自动播放的视频，可延迟到用户 hover 播放按钮或点击时再设置
- 绝对不要给
display: none或visibility: hidden的<video>提前赋值 poster——旧版浏览器仍可能触发无效请求 - 服务端渲染（SSR）场景下，可内联极小的 data URL 保底，如
poster="data:image/png;base64,iVBORw0KGgo..."，避免首屏白屏
WebP + 尺寸匹配 + 质量 70 是实测有效的组合
一张 1280×720 的 WebP 图，在质量设为 70 时，体积通常压到 40 KB 左右——这刚好低于 iOS Safari 对 poster 的敏感阈值（200 KB），又足够支撑 LCP 指标。关键点在于：
- 宽高比必须与视频严格一致（如 16:9 视频就用 1280×720），否则缩放会模糊或触发重绘
- 优先用 WebP（Chrome/Firefox/Safari 16.4+ 全支持；iOS Safari 14+ 也兼容），fallback 到 JPEG，不用 PNG（体积大）
- 别盲目追求 100% 质量；65–75% 是清晰度与体积的最优平衡点
- 导出时禁用 ICC Profile 和元数据，进一步压缩体积
必须配 preload="metadata"，且动态更换要强制刷新
iOS Safari（尤其 15–16）不设 preload="metadata"，poster 可能完全不显示，直到点击播放才闪一下。这不是 bug，是它把 poster 当作“非关键资源”处理。同时，动态更换 poster 不能只改属性：
立即学习“前端免费学习笔记（深入）”；
- 必须先
videoEl.removeAttribute('poster')，再setAttribute('poster', ...) - 最后必须调
videoEl.load()强制刷新（注意：这会清空已缓冲的视频数据） - 海报加载失败不会触发
error事件，得用new Image()预加载校验，失败则 fallback 到 base64 占位图或纯色背景（如background: #1a1a1a）
真正难的不是让 poster “出现”，而是在不同设备、不同网络、不同缓存状态下，让它始终以可控方式出现——这意味着你要放弃“写一次就完事”的想法，转而把 poster 当作一个需要主动管理的资源状态，而不是一个静态属性。
