必须用 srcset + sizes 精准匹配 CSS 布局宽度，按断点写 sizes 表达式并统一单位；picture 中 source 须按格式兼容性从高到低排序，WebP/AVIF 在前、JPEG/PNG 在后；img 必须设置 width/height 防 layout shift。
大规模营销活动期间，图片流量常占总带宽 60% 以上；单纯压缩或加 loading="lazy" 不足以缓解峰值压力——必须让浏览器在 HTML 解析阶段就精准加载「刚好够用」的图，否则 CDN 带宽账单会飙升。
srcset + sizes 必须与真实 CSS 布局对齐
很多团队把 sizes 写成固定值（如 sizes="100vw"），结果活动页在桌面端仍拉下 2400w 图片，而实际容器宽度只有 720px。这不是浏览器选错，是你没告诉它真实渲染宽度。
- 先写好所有断点下的 CSS：
@media (min-width: 768px) { .hero-img { width: 720px; } } - 再转成
sizes表达式：sizes="(max-width: 767px) 100vw, 720px"（注意单位统一为vw或px，不能混用rem） - 如果用了
max-width: 100%且父容器有 padding，sizes要减去 padding：比如容器padding: 0 20px，视口宽 390px，则有效宽度 ≈350px，对应sizes="(max-width: 767px) 350px, 720px"
picture 中的 source 顺序决定 fallback 逻辑
浏览器从上到下匹配 <source>，遇到第一个 media 匹配且 type 受支持的就停止。营销页常需 WebP 优先 + JPEG 降级，但若把 JPEG 放前面，旧版 Safari 就永远加载不到 WebP。
- WebP/AVIF 必须排在 JPEG/PNG 前面：
<source type="image/webp" ...>→<source type="image/jpeg" ...> - 同一
<source>内不能混用w和x描述符，否则部分 Android 浏览器会忽略整条srcset - 避免冗余
<source>：只保留你真实 CSS 媒体查询中触发的断点，比如只在@media (min-width: 1200px)切布局，那<source media="(min-width: 1440px)">就是无效项
img fallback 的 width/height 不是可选项
没设 width 和 height 的 <img> 在加载完成前不占空间，导致 layout shift——用户看到内容跳动，LCP（最大内容绘制）指标恶化，间接拉长感知加载时间，逼得 CDN 更早发大图来“抢时间”。
立即学习“前端免费学习笔记（深入）”；
- 给
<img>加内联width和height，按原始图比例填（如 1200×800 图写width="1200" height="800"） - 配合 CSS
aspect-ratio: 1200 / 800更稳妥，但 Safari padding-top 技巧降级 -
object-fit: cover不解决占位问题，它只控制裁剪方式，容器尺寸仍由width/height或aspect-ratio决定
超大图必须预生成多档位，不能靠前端“缩放”
直接 <img src="banner-10MB.jpg"> 即使加了 sizes 也没用——浏览器仍要下载全量文件。营销 Banner 常见 5–10MB TIFF/JPEG 原图，必须服务端提前切出梯度档位。
- 推荐尺寸梯度：
400w/800w/1200w/1600w（覆盖手机到 2x 大屏） - 用
convert -resize 1600x -quality 85 -interlace Plane输出渐进式 JPEG，首帧更快可见 - 禁用
.tiff、未压缩.png上线；现代浏览器已全支持image/avif，体积比 WebP 再小 20% - CDN 配置自动转码（如 Cloudflare Image Resizing）仅作兜底，不能替代预生成——它增加首字节延迟，且不支持 AVIF
最易被忽略的点：所有 sizes 表达式必须基于实测渲染宽度，而不是设计稿标尺；所有 srcset 档位必须和 CSS 断点严格对应，多一个或少一个都可能让带宽在百万 UV 活动中多支出数万元。
