一、图片为什么最容易成为性能黑洞#

一个典型页面里，图片往往是体积最大的一类资源：HTML 十几 KB，CSS 几十 KB，JS 打包后上百 KB，而一张没处理过的手机照片随手就是 3–5 MB。

更麻烦的是，图片的体积问题会直接传导到 LCP（Largest Contentful Paint）——绝大多数页面的 LCP 元素就是一张图片。你辛苦做的代码分割和 CSS 精简，很可能被一张没压缩的 PNG 一次性抹平。

图片优化看起来很简单——「压一压就好了」——实际上它由三个互相独立的问题组成：

三者必须分别解决。只做了格式转换，相当于给一台 4000px 宽的巨幅图换了个更省油的发动机——油是省了，车还是那么大。

NOTE

还有第四个问题：稳定性。图片没有预留尺寸会导致布局跳动，这是 CLS 的问题而不是 LCP 的问题，放在第六节单独讲。

二、格式：JPEG、WebP、AVIF 怎么选#

先看一张对照表。这里的「支持」指各浏览器开始支持的版本，具体版本号可以随时在 caniuse 或 Web Platform Features Explorer 上复核：

关于编码效率，业界常见的大致结论是：同等主观画质下，WebP 通常比 JPEG 小 25%–35%，AVIF 又能在 WebP 基础上再小 20%–30%。具体数字取决于图像内容，线条多、渐变色块的图差异会更明显，噪点多的照片差异会小一些。不要照搬任何百分比，用自己的图跑一遍对比才有意义。

三、尺寸：srcset 与 sizes 的选择算法#

格式确定了「怎么编」，接下来要解决「发多大」。

核心矛盾是：服务端在发 HTML 的时候，并不知道客户端要拿多大的图。屏幕宽度、DPR、以及这张图在布局里的实际宽度，都只有浏览器自己清楚。所以标准给出的解法不是「服务端猜」，而是服务端提供一组候选，浏览器自己挑。这就是 srcset + sizes。

1
<img
2
  src="/img/cover-960.jpg"
3
  srcset="/img/cover-480.jpg   480w,
4
          /img/cover-960.jpg   960w,
5
          /img/cover-1440.jpg 1440w"
6
  sizes="(min-width: 1024px) 720px, 100vw"
7
  width="1440" height="960"
8
  alt="示例封面"
9
  loading="lazy"
10
  decoding="async"
11
>

这几行里，两个属性的分工是完全不同的：

• srcset 用 w 描述符声明每个候选文件的真实像素宽度——注意是「文件有多宽」，不是「它将被显示成多宽」；
• sizes 声明这张图在布局中会占多宽——它是一组媒体条件 + CSS 长度，描述的是槽位（slot），跟具体文件无关。

浏览器的选择过程大致是三步：

1. 解析 sizes，得到当前视口下这张图的槽位宽度（CSS 像素）；
2. 槽位宽度 × 当前 devicePixelRatio，得到需要的物理像素宽度；
3. 在 srcset 里挑第一个不小于该宽度的候选；如果全都比它小，就选最大的那个。

举个具体的例子：视口 1440px，命中 (min-width: 1024px) 720px，槽位是 720px；设备 DPR = 2，于是需要 1440 物理像素，浏览器选中 cover-1440.jpg。同一台设备如果 DPR = 1，只需要 720px，就会选中 cover-960.jpg。

1
<img src="thumb.jpg" srcset="thumb-240.jpg 240w, thumb-480.jpg 480w"
2
     sizes="auto, 100vw" loading="lazy" alt="缩略图">

四、<picture>：当「同图不同尺寸」不够用#

srcset 只能做一件事：同一张构图，不同分辨率。但有两类需求它表达不了：

1. 艺术指导（art direction）：窄屏上需要换一张不同构图的图——比如宽屏用 16:9 横幅，手机上换成居中的方形裁切。这不是缩放，是另一个文件；
2. 格式回退：同一张图提供 AVIF / WebP / JPEG 三个版本，让浏览器按支持情况自己挑。

<picture> 把这两件事统一成了「一组候选源 + 一个兜底 <img>」：

1
<picture>
2
  <!-- 1. 窄屏艺术指导：方形裁切的 AVIF -->
3
  <source
4
    media="(max-width: 640px)"
5
    type="image/avif"
6
    srcset="/img/hero-square-480.avif 480w,
7
            /img/hero-square-960.avif 960w"
8
    sizes="100vw">
9

10
  <!-- 2. 宽屏 AVIF -->
11
  <source
12
    type="image/avif"
13
    srcset="/img/hero-wide-960.avif 960w,
14
            /img/hero-wide-1920.avif 1920w"
15
    sizes="100vw">
16

17
  <!-- 3. 宽屏 WebP 回退 -->
18
  <source
19
    type="image/webp"
20
    srcset="/img/hero-wide-960.webp 960w,
21
            /img/hero-wide-1920.webp 1920w"
22
    sizes="100vw">
23

24
  <!-- 4. 兜底：必填 -->
25
  <img
26
    src="/img/hero-wide-1920.jpg"
27
    width="1920" height="1080"
28
    alt="首页主视觉"
29
    fetchpriority="high"
30
    decoding="async">
31
</picture>

选择规则很简单：浏览器从上往下看，选中第一个 media 匹配且 type 支持的 <source>，然后在这个 <source> 内部再跑一次第三节的 srcset/sizes 算法。一个都不匹配，就用最后的 <img>。

几个容易踩的点：

• <img> 是必需的，不是可选的装饰。它同时承担「最终回退」和「语义与可访问性」两个职责——alt 只能写在它上面；
• width/height 也要写在 <img> 上。写在 <source> 上无效，占位就白做了（见第六节）；
• sizes 在每个 <source> 里是独立的。上面的例子里，方形裁切和宽幅横幅的布局宽度不同，所以各自的 sizes 也不同；
• 别把 media 写反。窄屏条件要放在前面，否则宽屏条件会先把所有视口都吃掉。

WARNING

<picture> 里不要给 <img> 加 srcset。这会让「哪个属性在起作用」变得难以推理；格式回退和尺寸选择都应该在 <source> 里表达，<img> 只留一个 src 兜底。

五、时机：loading、fetchpriority 与 preload#

格式和尺寸解决的是「下多少」，接下来解决「什么时候下」。

1
<img src="/img/hero-1920.jpg" fetchpriority="high" alt="首页主视觉">

1
<link rel="preload" as="image"
2
      type="image/avif"
3
      imagesrcset="/img/hero-960.avif 960w, /img/hero-1920.avif 1920w"
4
      imagesizes="100vw"
5
      fetchpriority="high">

六、稳定性：别让图片把页面顶来顶去#

图片在加载完成前高度是 0，加载完成后突然撑开——如果它上面正好有内容，那些内容就会被顶下去。这就是 CLS（Cumulative Layout Shift）最常见的来源。

解法本身极其简单：让浏览器在图片下载完成之前就知道它要占多大地方。

1
<img src="/img/cover.jpg" width="1440" height="960" alt="封面">

只要同时写上 width 和 height，浏览器就能算出宽高比，在图片还没到的时候先把空间预留出来。这两个值不需要和实际显示尺寸一致，它们只用来推导比例。

配套的 CSS 有一条容易漏掉的规则：

1
img {
2
  max-width: 100%;
3
  height: auto;  /* 关键：否则 height 属性会胜出，图片被压扁 */
4
}

height: auto 是必须的。省略它的话，HTML 上的 height="960" 会硬性生效，图片在窄容器里就会被拉伸变形。

对于固有尺寸未知的图（用户上传、远程 URL），用 CSS 显式声明比例：

1
.thumb {
2
  width: 100%;
3
  aspect-ratio: 4 / 3;
4
  object-fit: cover;      /* 按比例裁切，不拉伸 */
5
  background: #f3f4f6;    /* 占位底色，避免白块闪烁 */
6
}

aspect-ratio 配合 object-fit: cover，可以在不知道原图尺寸的前提下做出稳定的等比缩略图——这是列表页和卡片流的标配。

七、落地：构建期生成多尺寸多格式#

以上的规则讲完了，但在实际项目里，没有人会手写这些 srcset。正确做法是让构建流程从原图自动生成变体，模板只负责输出。

用 sharp 写一个最小可用的生成器：

1
import sharp from 'sharp'
2
import { mkdir } from 'node:fs/promises'
3

4
const WIDTHS = [480, 960, 1440, 1920]
5

6
// effort 越低编码越快、体积略大——构建时间敏感时优先调它
7
const FORMATS = {
8
  avif: { quality: 50, effort: 4 },
9
  webp: { quality: 72 },
10
  jpeg: { quality: 80, mozjpeg: true },
11
}
12

13
export async function buildVariants(input, outDir, basename) {
14
  const { width: sourceWidth } = await sharp(input).metadata()
15
  await mkdir(outDir, { recursive: true })
16

17
  const variants = {}
18

19
  for (const width of WIDTHS) {
20
    // 不放大：原图比目标窄就跳过，否则只是徒增体积
21
    if (sourceWidth < width) continue
22

23
    for (const [ext, options] of Object.entries(FORMATS)) {
24
      const file = `${outDir}/${basename}-${width}.${ext}`
25
      await sharp(input)
26
        .resize({ width, withoutEnlargement: true })
27
        [ext](options)          // avif() / webp() / jpeg()
28
        .toFile(file)
29
      ;(variants[ext] ??= []).push({ width, file })
30
    }
31
  }
32

33
  return variants
34
}

几个值得注意的实现细节：

• withoutEnlargement: true 不能省。原图只有 600px 宽时，把它”放大”到 1440px 只会得到一个更模糊、更大的文件；
• sourceWidth < width 的显式跳过与上一条是双保险。前者的收益是少生成一批废文件，后者保证即使 resize 被调用也不会放大；
• AVIF 的 effort 是构建时间的最大变量。默认值追求压缩率，在大批量图片上可能让构建慢到无法接受；先把它调低跑通，再按需提高；
• 产物文件名带内容哈希，配合 Cache-Control: public, max-age=31536000, immutable，图片就能长期缓存在 CDN 和浏览器里，永远不会因为”图变了但 URL 没变”而出问题——这部分细节可以看《HTTP 缓存策略完全指南》。

生成完之后，把结果喂给模板。用 astro:assets 的话这一步是内置的——<Image> 和 <Picture> 组件会在构建期完成多尺寸、多格式的生成并输出正确的 srcset，本站的图片就是这么处理的（实测数据见《本站浏览器支持与多端适配报告》：横幅图提供 480–1920 共八档，卡片封面按实际尺寸生成）。自己写构建脚本的意义在于：你清楚每一个字节是怎么来的，出了问题知道去哪里查。

八、上线前的图片检查清单#

第 9 条最值得养成习惯。它把前面所有”理论上应该选中某某”的推理，变成一次可观测的验证：打开 DevTools，选中 <img>，在元素面板旁的提示里查看当前实际使用的候选源；再切换设备模拟器的 DPR，看候选是否随之改变。如果 DPR 从 1 切到 2 而选中的文件没变，基本可以断定是 sizes 写错了。

参考资料#

• MDN：<img> 元素
• MDN：图像格式与浏览器支持
• MDN：<picture> 元素
• MDN：fetchpriority 属性
• Web Platform Features Explorer：AVIF
• Web Platform Features Explorer：fetch-priority
• sharp：输出选项与编码参数