<picture>本身不提速，真正影响加载速度的是media、srcset、sizes和type是否精准匹配布局与设备能力；常见问题包括media缺括号、type与Content-Type不一致、sizes单位错误、断点重叠、srcset冗余、w/x混用、type顺序错乱、AVIF兼容性不足、lazy无效及缺少宽高属性。
media、srcset、sizes 和 type 是否精准匹配实际布局与设备能力。
为什么写了 <picture> 还是只加载兜底图
这是最常见也最容易被忽略的“假优化”：浏览器根本没进任何 <source> 分支，直接跳到 <img src="...">。原因往往藏在语法细节里：
-
media值缺括号：写成media="max-width: 768px"❌，必须是media="(max-width: 768px)"✅ -
type与服务器返回的Content-Type不一致：比如写了type="image/webp"，但 Nginx 实际返回text/plain或image/webp（末尾空格）——Chrome 会标为blocked:mime-type -
sizes没单位或错配 CSS：写成sizes="50vw"✅，但写成sizes="50%"或sizes="300px"❌；更隐蔽的是，如果 CSS 里图宽其实是calc(100% - 2rem)，而sizes写了"100vw"，浏览器就会误判显示宽度，拉大图 - 多个
media断点重叠：比如(max-width: 768px)和(min-width: 768px)在 768px 宽度时行为未定义，建议用开区间：(max-width: 767px)→(min-width: 768px)→(min-width: 1201px)
srcset 里塞太多尺寸反而拖慢解析
浏览器在 HTML 解析阶段就要遍历整个 srcset 列表，计算每个候选图是否可能被选中。哪怕某个 400w 图永远用不上，它也会参与预加载决策。
- 只保留真实 CSS 媒体查询中触发的断点宽度：比如你只在
@media (min-width: 768px)和@media (min-width: 1200px)改布局，那srcset就只需覆盖768w、1200w、1920w三个档位 - 别混用
w和x：同一srcset中只能选一种描述符。写"photo@1x.jpg 1x, photo@2x.jpg 2x"✅；混写"photo-400w.jpg 400w, photo@2x.jpg 2x"❌（Safari 可能整条跳过） - 用 Chrome DevTools → Network 面板禁用缓存多刷几次，看哪些
img请求压根没发出去——那些就是冗余项
type 顺序决定格式优先级，不是自动降级
浏览器从上到下逐个检查 <source>，遇到第一个 type 受支持且 media 匹配的就停，不会继续往下试。所以 WebP / AVIF 必须放 JPEG 前面。
- 正确顺序：
<source srcset="hero.avif" type="image/avif">→<source srcset="hero.webp" type="image/webp">→<img src="hero.jpg" alt="..."> - 每个
<source>的srcset要独立适配：WebP 版本的srcset里不要混 JPEG 路径，否则匹配失败后不会 fallback 到下一条<source>，而是直接走<img> - AVIF 虽压缩率高，但编码耗 CPU；iOS Safari 目前（2026 年中）仍不支持，别把它放在唯一路径上
懒加载和 <picture> 能一起用，但别信 loading="lazy"
loading="lazy" 对 <picture> 无效——它只作用于直接子元素，而 <picture> 的子元素是 <source> 和 <img>，<source> 不是可渲染元素，<img> 的 loading 属性又常被浏览器忽略。
立即学习“前端免费学习笔记（深入）”；
- 首屏关键图（如 banner、logo）必须移除所有懒加载逻辑，否则可能白屏或 FOUC
- 非首屏图建议用
IntersectionObserver+ 手动切换data-srcset到srcset，而不是依赖原生 lazy -
<picture>内部的<img>一定要设width和height（内联属性，不是 CSS），值按原始图比例来，否则没有占位空间，加载完成瞬间触发 layout shift，用户感知就是“卡了一下”
真正卡住加载速度的，从来不是标签怎么写，而是你有没有让浏览器“算得清、选得准、不瞎试”。<picture> 是把选择权交出去，但前提是你给的选项既合法又合理。
