问题出现得很突然，日志倒是留得挺全。移动端 LCP 3.5 秒，抓包发现首屏轮播一次加载了三张 1200px 宽的图，单张 480KB，4G 网络下光图片就要两秒多。
刚开始盯着「图片格式还是 jpg，没有走 webp 或 avif」，折腾了半个多小时，排掉了。
这类报错背后常见的原因有几处，逐个排除就行。img 没有配 srcset，移动端直接拿桌面大图。少数情况下是轮播的三张图都在首屏预加载，只有第一张是可见的。
不容易想到的是，图片服务器没有开压缩，原图直出。
上来先确认移动端实际拿到的图片宽度
curl -s -A "Mozilla/5.0 (iPhone)" https://www.example.com/ | findstr /i srcset然后对比不同尺寸文件的体积
curl -sI https://www.example.com/img/hero-1200.jpg | findstr /i content-length给首屏图加 srcset 与 sizes
echo '<img src="hero-800.jpg" srcset="hero-480.jpg 480w, hero-800.jpg 800w" sizes="100vw">';只预加载第一张轮播图
echo '<link rel="preload" as="image" href="/img/hero-480.jpg" media="(max-width:768px)">';当时还开着另一个排查窗口，两边日志对照着看才定位到。
改完先别撤，确认这几项。加上 srcset 并只预加载首图后，移动端 LCP 降到 2.3 秒，首屏传输量少了六成。
容易忽略的是，移动端首屏图要单独出尺寸，srcset 不加，响应式布局也救不了加载体积。如果同一现象隔几天又出现，说明根因没找到，别当偶发处理。