掌握picture标签的响应式图片最佳实践

优化前：卡得不行

上周上线了一个新项目，首页是几个大图轮播 + 商品展示，本来觉得设计挺清爽的，结果用户反馈加载慢，尤其是手机端，进页面要等五六秒才看到内容。我自己拿台旧 iPhone 试了下，确实卡得不行，首屏图片加载完都快半分钟了，Lighthouse 直接给我打了 38 分，Performance 这一项绿条短得可怜。

最离谱的是，明明我用了懒加载，也压缩了图片，但 Network 面板里显示那些图还在请求 2MB 多的原图，而且是 WebP 格式都没生效。一开始我以为是 CDN 缓存没更新，清了好几遍还是老样子。最后发现，问题出在图片响应式适配上 —— 我只用了一个 srcset，根本没考虑浏览器兼容性和设备像素比的实际表现。

找到瘼颈了！

我打开 Chrome DevTools 的 Network 面板，按资源类型过滤，一眼就看到一堆 image 请求，每个都几百 KB 到几 MB 不等。更气人的是，很多明明是给移动端看的图，居然加载的是桌面端的大图，比如 1920px 宽的那种。这说明 srcset 虽然写了，但浏览器压根没选对。

后来我查 MDN 文档，发现一个关键点：srcset 只支持基于分辨率或宽度的提示，但它不会根据 MIME 类型做优先级判断。也就是说，就算你写了 image.webp 2x，如果浏览器不支持 WebP，它还是会下载这个资源，然后报个格式错误或者干脆不显示。

这时候我才意识到，得上 picture 元素了。之前一直懒得改，觉得 img + srcset 够用，但现在这情况，不用真不行。

核心方案：用 picture 打通多格式+响应式链路

我重构了所有关键图片的写法，把原来的 img 换成 picture，结构清晰多了。主要思路是：

• 先用 source[type=”image/webp”] 提供高性能格式
• 再 fallback 到 JPEG/PNG
• 配合 media 属性做屏幕宽度适配
• 最后用 srcset 控制 DPR（设备像素比）

这样浏览器会自动选最合适的资源，而不是瞎猜。

优化前的代码长这样：

<img 
  src="/images/hero-1920.jpg" 
  srcset="/images/hero-768.jpg 768w, /images/hero-1080.jpg 1080w, /images/hero-1920.jpg 1920w"
  alt="Hero Banner"
  loading="lazy"
/>

看着好像做了响应式，但实际上所有设备都会尝试加载 WebP 不友好的资源，而且没有格式控制。

优化后的版本：

<picture>
  <!-- WebP for modern browsers -->
  <source 
    media="(min-width: 1024px)" 
    srcset="
      /images/hero-1920.webp 1920w,
      /images/hero-1440.webp 1440w,
      /images/hero-1080.webp 1080w
    " 
    type="image/webp"
  >
  <source 
    media="(min-width: 768px)" 
    srcset="
      /images/hero-1080.webp 1080w,
      /images/hero-768.webp 768w
    " 
    type="image/webp"
  >
  <source 
    media="(max-width: 767px)" 
    srcset="
      /images/hero-480.webp 480w,
      /images/hero-320.webp 320w
    " 
    type="image/webp"
  >

  <!-- Fallback JPEG -->
  <source 
    media="(min-width: 1024px)" 
    srcset="
      /images/hero-1920.jpg 1920w,
      /images/hero-1440.jpg 1440w,
      /images/hero-1080.jpg 1080w
    " 
    type="image/jpeg"
  >
  <source 
    media="(min-width: 768px)" 
    srcset="
      /images/hero-1080.jpg 1080w,
      /images/hero-768.jpg 768w
    " 
    type="image/jpeg"
  >
  <source 
    media="(max-width: 767px)" 
    srcset="
      /images/hero-480.jpg 480w,
      /images/hero-320.jpg 320w
    " 
    type="image/jpeg"
  >

  <!-- Final fallback -->
  <img 
    src="/images/hero-320.jpg" 
    alt="Hero Banner"
    loading="lazy"
    width="320"
    height="200"
  >
</picture>

这里有几个细节我踩过坑：

• type 必须写对：不然 WebP 根本不会被识别，Chrome 都可能跳过
• media 查询要覆盖全：别漏了中间断点，否则可能出现“空档期”，浏览器乱选
• source 顺序很重要：虽然理论上按匹配优先级来，但为了保险，我还是把高优先级的放前面
• 最终 img 的 src 是兜底：哪怕所有都不支持，至少还能显示一张小图

另外我还加了个构建脚本，用 Sharp 自动批量生成 WebP 和不同尺寸的版本，避免手动处理出错。这部分就不贴了，反正就是 Node.js 跑个循环压缩。

顺手做的其他优化

除了换 picture，我还顺手做了几件事，虽然不是主角，但也贡献了不少性能提升：

• 给所有图片加了 loading="lazy"，不过现在基本默认开启了
• 设置了明确的 width 和 height，防止布局偏移（CLS 降了不少）
• 通过 fetchpriority="high" 提升首屏关键图的加载优先级（仅限现代浏览器）
• 把非首屏的 picture 包一层 IntersectionObserver 做懒加载

优化后：流畅多了

改完重新部署，本地和线上测了一圈，终于不卡了。重点数据如下：

• 首屏图片平均加载时间从 5.2s 降到 830ms
• Lighthouse Performance 分数从 38 升到 89
• 首字节时间（TTFB）没变，但 DOMContentLoaded 从 6.1s 降到 2.3s
• 总图片传输体积减少约 67%
• WebP 使用率从 0% 提升到 82%（Android 和 Chrome 主力用户受益最大）

最关键的是用户体验变了——以前进去先看白屏三四秒，现在几乎是秒出内容，尤其是中低端安卓机，提升特别明显。

当然也有小遗憾：iOS Safari 对 WebP 支持是从 iOS 14 开始的，所以还有少量用户走的是 JPEG 路径。但这部分占比不到 15%，而且我们也没打算为了这点人搞额外兼容逻辑，毕竟维护成本太高。

性能数据对比

这是优化前后两个版本在同一设备（Pixel 4a，慢速 3G 模拟）下的表现：

可以看出，LCP 和 CLS 都大幅改善，这两个是 Google Core Web Vitals 的核心指标，直接影响 SEO 排名。

踩坑提醒：这三点一定注意

折腾了半天才发现这几个坑，记下来省得后面人再踩：

1. 不要以为 WebP 万能。有些 Android 浏览器（比如某些厂商定制壳）虽然支持 WebP，但 decode 性能极差，反而拖慢渲染。建议对低端设备做 JS 检测后动态切换格式，不过我们这次没上这么复杂。
2. CDN 缓存要注意缓存 key 是否包含 Accept 请求头。如果不包含，那就算客户端支持 WebP，也可能返回 JPEG 缓存。我们用的是 Cloudflare，默认开了「Polish」和「Responsive Images」，还算靠谱。
3. picture 里的 img 标签不能省。哪怕你写了再多 source，只要最后没 img，页面就会出现空白。我有一次打包时误删了，线上炸了半小时。

以上是我的优化经验，有更优的实现方式欢迎评论区交流

这个方案不是最炫的，也不是全自动的，但它稳定、可控、效果实打实。如果你也在做内容型站点或者电商首页，强烈建议把 picture 元素用起来，别再靠单一 srcset 硬撑了。

后续我可能会接入 client hints 做服务端适配，但现在浏览器支持还不够广，先这样凑合着用吧。前端优化就是这样，永远没有完美解，只有“够用”和“更麻烦”的区别。