2026 年 8 月我们给一个官网改图片，改之前首屏图片总重 3.8 兆，改完 1.1 兆，视觉上看不出差别。做法不复杂：一张图准备三个尺寸，让浏览器自己挑。
一张图三个尺寸
手机竖屏大概需要 400 到 600 像素宽，平板 800 到 1000，桌面 1400 到 1600。
只做这三个就够，没必要给每个断点都生成一版。尺寸太多，构建和缓存都变复杂。
高分辨率屏要乘 2，所以桌面最大那张要准备 2800 像素左右的版本。这是文件变大主要来源，但也只在必要时加载。
srcset 和 sizes 怎么写
srcset 列出候选图片和宽度，sizes 告诉浏览器这张图在不同视口下占多宽。
最常见的错是 sizes 写死 100vw。图片实际只占一半宽度，浏览器却按整屏挑图，结果加载了双倍大小的文件。
sizes 写不对，srcset 就白配。这条我们踩过，改完发现流量只降了一成，问题就在 sizes。
格式怎么选
优先 AVIF，其次 WebP，最后才是 JPEG 和 PNG。用 picture 标签做回退，浏览器自己选支持的最好格式。
质量参数别设满。照片类 70 到 80 就够，人眼很难分辨，文件能小一半。
截图和带文字的图要另说，压缩过头会糊，这类图控制在 85 左右。
图片 CDN 能省很多事
图片放 CDN，URL 里带参数控制宽高和格式，不用提前生成多份。
一张原图，通过参数输出 400、800、1600 三个版本，缓存也由 CDN 管。改动成本比构建时生成低。
注意缓存策略。参数不同就是不同资源，URL 变了缓存要重新建，第一次访问会慢一点。
三个容易踩的坑
第一个，首屏那张图加了懒加载。LCP 图必须优先加载，懒加载会把它推到很后面。
第二个，显示尺寸和实际尺寸不一致。CSS 里显示 300 像素宽，加载的是 1600 像素的图，白白浪费七成流量。
第三个，图片没有宽高比。这会同时拖慢 LCP 和造成 CLS，等于两个指标一起坏。
一个省事的构建配置
站点如果用现代框架，图片组件一般能自动生成 srcset。手写容易漏尺寸，配置一次省事很多。
我们的默认输出是三个宽度加两种格式，构建时生成，交给 CDN 缓存。新图片进来不用单独交代。
一个态度
图片优化是首屏优化里收益最确定的一件事。软件公司的官网尤其明显，因为首屏往往就是一张产品截图。
但它需要设计和开发配合。设计稿出图的时候就要约定输出规格，别等上线了再回头改。
我们的默认要求是：新建页面提测时，首屏图片总量不超过 500KB，超过就不让上线。
元析智能
为软件公司做 SEO 和 GEO 优化