先把当时的情况摆出来。改版把首屏主图换成了自动播放的 MP4，Chrome 性能面板里 LCP 从 2.2 秒涨到 4.1 秒，压缩图片、换 webp 都做了，数字没有变化。
原因不止一个，得分开看。video 带 autoplay 时会抢占带宽，图片请求被排在后面。少数情况下是poster 图片没有预加载，浏览器要等视频元数据返回才渲染首帧。
不容易想到的是，视频文件放在源站，没有走 CDN，首字节就要 800ms。还有一种情况，preload 设成 auto，整段视频在首屏就开下载。
上来先确认 LCP 元素到底是什么
curl -s https://www.example.com/ | findstr /i "<video"然后看视频文件的响应时间
curl -s -o NUL -w "ttfb=%{time_starttransfer} total=%{time_total}\n" https://www.example.com/media/hero.mp4给 poster 加预加载并改 preload 策略
echo '<link rel="preload" as="image" href="/img/hero-poster.jpg">';剩下的就是把视频挪到 CDN 并开分片
curl -sI https://cdn.example.com/media/hero.mp4 | findstr /i "HTTP content-length"手上没有现成的复现脚本，就照着线上请求手工拼了一个。
别只看报错消失，验证要多做一步。poster 预加载加视频走 CDN 后，LCP 回到 2.1 秒，移动端 75 分位进入绿色区间。
首屏视频的 LCP 由 poster 决定，不是由视频本身，压视频文件往往解决不了这个问题。监控比日志更早给出信号，事后回看经常能提前半小时发现异常。