用 srcset + sizes 实现 webp 优先降级是最可控的带宽压缩手段；缺失 sizes 会导致浏览器按 100vw 加载远超实际需要的大图，sizes 必须含单位且匹配真实布局，srcset 用 w 描述符更适配电商布局图，picture 中 type 顺序决定降级可靠性，webp 必置最前。
直接结论：用 srcset + sizes 配合 <picture></picture> 实现 WebP 优先降级，是电商大促期间最可控、可量化的带宽压缩手段；单纯靠 CSS 缩放或只写 srcset 不配 sizes，等于没做响应式。
为什么 sizes 缺失会导致带宽浪费严重
浏览器不会“猜”你这张图在页面里占多宽——它必须依赖 sizes 提供的渲染宽度估算值，再从 srcset 中选最接近但不小于该宽度的源。漏掉 sizes，浏览器默认回退到 100vw，哪怕你实际只给卡片留了 320px 宽度，在 1440px 视口下也会加载 1200w 甚至 1920w 的图。
-
sizes必须存在，且单位不能省（"50vw"合法，"50"无效） - 常见错误写法：
sizes="480px"—— 这在高 DPR 设备（如 iPhone 14 Pro）上会强制选大图，因浏览器按物理像素匹配，不是逻辑像素 - 真实布局中，如果卡片容器用
max-width: 400px+margin: 0 auto，sizes应写成"(max-width: 768px) 90vw, 400px"，而非拍脑袋的"50vw"
srcset 用 w 还是 x？电商图一律选 w 描述符
电商主图、列表图、Banner 都是布局图（layout image），核心约束是“在视口里占多宽”，不是“设备 DPI 多高”。用 x 描述符（如 1x, 2x）只适合图标、按钮等小尺寸装饰性元素；对大图而言，它无法感知布局变化，容易在中屏设备（如 iPad Air）上加载双倍尺寸却只显示一半。
-
srcset="p-480w.webp 480w, p-800w.webp 800w, p-1200w.webp 1200w"是合理粒度，覆盖 99% 场景 - 生成 10+ 个尺寸版本（如 320w/375w/414w/480w…）是反模式：CDN 缓存命中率暴跌，存储成本翻倍，收益几乎为零
- 不要在
srcset里混用w和x，浏览器行为不可控，DevTools Network 面板里看不到Width请求头就说明没生效
picture 元素里 type 顺序决定格式降级是否可靠
<picture></picture> 不是炫技，是格式兜底开关。浏览器从上到下解析 <source></source>，遇到第一个 type 受支持且 media 匹配的就停。所以 WebP 必须放最前，AVIF 次之，JPEG 放最后——顺序错了，IE11 或旧 Android WebView 就直接 fallback 到 <img>，而你本意可能是让它加载 JPEG 而非白屏。
- 别在同一个
<source></source>里又写media又写type：比如<source media="(min-width: 768px)" type="image/webp"></source>，这会让部分 WebView 因解析歧义跳过整条规则 -
<img>标签必须存在，且自带src和srcset：它是语义锚点，也是不支持<picture></picture>的老浏览器唯一入口 - AVIF 压缩率虽高，但编码耗时长，大促期间务必预生成，别走 on-demand 转码链路，否则 CDN 回源压力暴增
真正难的是让 sizes 和真实 CSS 布局严丝合缝——很多团队写了响应式 CSS，却没同步更新 sizes，结果 DevTools 里看到的加载图永远比需要的大 2–3 倍。这不是浏览器问题，是你没告诉它“这张图到底多宽”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
