picture 标签加载慢，大概率是 srcset 里写了无效或冗余的图片源
浏览器会按 srcset 列表逐个检查候选图片是否匹配当前设备条件（像素密度、视口宽度），哪怕某个选项永远用不上，解析和网络预加载阶段也会参与计算。常见错误是把所有尺寸都堆进去，比如从 320w 到 3840w 每隔 100px 写一个，实际只在 768w、1200w、1920w 三个断点做适配。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 只保留真实 CSS 媒体查询中会触发的宽度点，例如你用
@media (min-width: 768px)切换布局，那srcset就只需覆盖768w和更大尺寸 - 避免混用
w和x单位——同一source元素里只能选一种，否则部分浏览器会忽略整个srcset - 用
chrome DevTools → Network → Disable cache多刷几次，看哪些img请求根本没发出去，那些就是冗余项
img 标签 fallback 未设 width/height 导致 layout shift，拖慢感知加载速度
picture 本身不解决回流问题，最终渲染还是靠内部的 img。如果没设 width 和 height，或者设的是 auto，浏览器无法预留空间，图片加载完成前占位空白，一渲染就触发重排，用户会觉得“卡了一下”——这不是网络慢，是渲染阻塞。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 给
img加内联width和height（如width="800" height="450"），值按原始图比例来，不是响应式尺寸 - 配合
aspect-ratio: 16/9CSS 属性更稳妥，但注意 safari 15.4+ 才完全支持，老版本需降级为padding-top技巧 - 别依赖
Object-fit: cover来“修图”，它不改变容器尺寸计算逻辑，该闪还是闪
没有用 sizes 属性，浏览器误判视口宽度导致下载大图
srcset 只告诉浏览器“我有这些图”，但没说“你在什么宽度下该用哪张”。如果没有 sizes，浏览器默认按 100vw 算，哪怕你的 img 实际只占 300px 宽，它也可能拉一张 1200w 的图下来——浪费带宽，首屏加载自然慢。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 写
sizes要对应 CSS 中的真实宽度逻辑，比如sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 33vw" - 用
DevTools → Elements → 查看 computed styles → width确认元素在各断点下的实际渲染宽度，再反推sizes值 - 别写死成
sizes="100vw"，除非你真要全屏图；移动端小图也常被误载大图，就是这个原因
WebP/AVIF 图片未开启服务端支持，picture 回退失效
picture 的 source 顺序是有意义的：浏览器从上到下找第一个能解码的格式。但如果服务器没配好 WebP MIME 类型（image/webp），或 nginx/apache 没启用 AVIF 支持，某些浏览器（特别是旧版 Safari）会跳过所有 source，直接走底部 img 的 src——结果你精心写的多格式策略全白搭，还平白多一次 html 解析开销。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用
curl -I https://yoursite.com/photo.webp检查响应头是否有Content-Type: image/webp - Safari 对 AVIF 支持较晚（ios 16.4+），且要求服务端明确声明
image/avif，光有文件后缀没用 - 本地测试时别只看 Chrome，用 Safari 的
Develop → User Agent模拟 iOS 设备，观察是否真走了source分支
真正卡住性能的，往往不是语法写错，而是 sizes 和 CSS 宽度对不上、服务端 MIME 配置漏掉、或者以为写了 srcset 就万事大吉，却没验证浏览器到底下了哪张图。