页面上一张 1920 宽的图，手机用户也得下载整张，然后浏览器再把它缩到 390 像素宽显示——流量浪费了五倍，加载慢了一截。srcset 就是让浏览器按屏幕宽度挑一个合适的版本，前提是你得先把这几个版本做出来。
为什么一张图不够
Core Web Vitals 里的 LCP（最大内容绘制）通常就是首屏那张大图。给手机用户一张 1920 宽、400KB 的图，LCP 很难进 2.5 秒；换成 480 宽、40KB 的版本，同样的网络下快一个量级。Google 的页面体验信号直接看这个数字。
反过来，桌面大屏只给 768 宽的图又会糊。所以需要几档尺寸，让浏览器自己选。
一张实用的断点表
断点按图片在页面里的实际显示宽度定，不是按屏幕宽度。对最常见的「通栏大图」和「正文配图」两种情况：
- 通栏大图（hero、横幅）：480、768、1200、1920 四档。覆盖手机、平板、笔记本、大屏。
- 正文配图（内容区最宽 800 左右）：400、800、1200 三档，1200 是给 1.5x 到 2x 屏幕的。
- 缩略图 / 卡片图（显示宽 300 左右）：300、600 两档。
档位不是越多越好。每多一档就多一次导出、多一份存储，而浏览器选图有容差，相邻档位差 1.5 到 2 倍最合理。四档已经覆盖九成以上的设备组合。
2x 版本要不要
Retina 和多数手机屏幕的像素密度是 2x 到 3x，显示宽 400 的图在这些屏幕上要 800 像素才清楚。上面表里的大档位其实已经在充当小档位的 2x 版本——768 是 390 宽手机的 2x，1200 是 600 宽内容区的 2x。
所以不需要单独再出一套「@2x」文件，只要断点之间保持 2 倍左右的间距，浏览器会按密度自动选高一档。
格式：WebP 为主，JPG 兜底
同样画质下 WebP 比 JPG 小 25% 到 35%，现代浏览器全部支持。做法是每个尺寸出 WebP，用 picture 标签给旧浏览器留一份 JPG 兜底；如果你的访客里 2020 年以前的浏览器已经可以忽略，直接只出 WebP 也行。
AVIF 更小，但在浏览器里编码慢得多，大批量导出时不划算。关于几种格式的取舍，AVIF、WebP、JPEG 对比说得更细。
批量导出整套尺寸
把要处理的图一起拖进批量图片处理，按档位跑几遍，每遍改一个宽度和后缀：
- 尺寸「宽度 480」，关「允许放大」，输出 WebP 质量 80%，文件名加后缀 -480。
- 同样设置改成 768、后缀 -768；再 1200、1920。
- 需要 JPG 兜底的话，输出改 JPG，后缀不变，再跑一轮。
每一轮几十秒，出来的 ZIP 文件名已经是 hero-480.webp、hero-768.webp 这种形式，直接传到图片目录。「允许放大」务必关掉，1000 像素的原图不会被拉到 1920 去。
单张图想顺手看看各档位的体积差别，用图片尺寸调整试一张就知道。
写进 HTML
通栏大图的写法：
<img src="hero-1200.jpg"
srcset="hero-480.webp 480w, hero-768.webp 768w, hero-1200.webp 1200w, hero-1920.webp 1920w"
sizes="100vw" width="1920" height="1080" alt="...">正文配图把 sizes 改成实际宽度，比如 sizes="(max-width: 840px) 100vw, 800px"。width 和 height 属性一定写，浏览器据此预留位置，页面不会跳。
做完这一步，再配合让图片加载更快里的懒加载和压缩建议，图片这一块的性能分基本就拿满了。