现场是这样的。文章封面用 picture 输出 avif 和 webp，source 里先写 1600px 的大图，后写 480px 的小图。移动端一直下 1600px 那张，单页图片流量比改版前还高了三成。
中间走过弯路，把「img 的兜底指向原图，前面的 source 全部失效」当成主因，改完现象没变。
真正麻烦的地方在于，几个原因的现象几乎一样。source 按文件大小排序而不是按媒体条件；每个 source 缺 media 或 sizes，浏览器只认第一个匹配；CDN 自动转码后又生成一套 srcset，两套规则冲突。
第一件事是看移动 UA 下实际加载的图
curl -s -A 'Mozilla/5.0 (iPhone)' https://www.example.com/article/1 | grep -A4 '<picture>'小图在前并补媒体条件
<source media="(max-width: 600px)" srcset="/img/cover-480.avif" type="image/avif">给 img 补 sizes
<img src="/img/cover-960.jpg" sizes="(max-width: 600px) 100vw, 960px">复测移动端图片体积
https://pagespeed.web.dev/同一份数据我导出了两份，一份留底，一份拿来试。
这类问题以前遇到过，但这次的触发条件和上次不一样。
恢复的判定其实很直接。移动端只下载 480px 版本，单页图片体积从 1.4MB 降到 380KB，LCP 同步改善。
容易忽略的是，picture 的匹配是从上往下第一个命中，顺序写反时后面的规则再精确也没有机会生效。改动前把原配置备份一份，出问题能马上回滚，这比任何技巧都实用。