CDN 图片优化不只是把 JPEG 批量转换成 WebP 或 AVIF。一个可靠的方案需要同时决定图片尺寸、编码质量、格式回退、内容协商、缓存键、缓存时间和源站保护，否则可能出现“新版浏览器收到旧格式”“不支持 AVIF 的客户端收到 AVIF”或缓存变体数量失控等问题。

通常应优先减少图片像素和尺寸，再选择更高效的编码格式。AVIF 往往具有更强的压缩潜力，WebP 的兼容性和编码成本更容易控制，而 JPEG、PNG 或 GIF 仍可能作为特定内容及旧客户端的回退。最终选择应以真实图片样本、目标浏览器、视觉质量和编码成本测试为准，而不是为所有图片套用同一个质量参数。

CDN 图片优化究竟要解决什么？

图片优化的目标是在可接受的视觉质量下，向每位访问者发送足够用、但不过量的数据。完整流程通常包含以下几层：

1. 根据页面布局生成适合的宽度和像素密度。

2. 根据图片类型选择有损或无损压缩。

3. 根据浏览器能力选择 AVIF、WebP 或回退格式。

4. 由 CDN 缓存最终变体，避免每次请求都重新转换。

5. 通过日志和真实用户数据检查传输量、命中率、LCP 和错误率。

现代格式不能弥补尺寸错误。一张以 AVIF 编码、宽度 3000 像素的图片，如果只在 360 像素的手机卡片中显示，仍然可能比尺寸正确的 WebP 或 JPEG 浪费更多流量。

WebP、AVIF、JPEG 和 PNG 怎么选？

不要直接使用“AVIF 一定比 WebP 小”作为生产规则。照片、截图、透明图、插画和带文字图片的编码表现不同。应选取网站中有代表性的样本，以相近主观质量或可接受的质量指标比较文件大小，并检查色彩、渐变、锐利边缘、肤色与透明区域。

优先使用 HTML 的 picture 和 srcset，还是使用 Accept 协商？

两种方式都可行，但缓存和运维模型不同。

方案一：在 HTML 中明确列出格式

<picture>
  <source
    type="image/avif"
    srcset="/images/hero-700.avif 700w,
            /images/hero-1400.avif 1400w">
  <source
    type="image/webp"
    srcset="/images/hero-700.webp 700w,
            /images/hero-1400.webp 1400w">
  <img
    src="/images/hero-700.jpg"
    srcset="/images/hero-700.jpg 700w,
            /images/hero-1400.jpg 1400w"
    sizes="(max-width: 700px) 100vw, 700px"
    width="700"
    height="394"
    alt="示例图片">
</picture>

这种方式让每个格式和尺寸拥有独立 URL，CDN 缓存逻辑直观，浏览器自行选择支持的格式和合适候选图。它适合可以在构建或上传阶段预生成变体的网站，也是静态站点中更容易排查的方案。

方案二：同一 URL 根据 Accept 返回不同格式

浏览器请求图片时，通常会在 Accept 请求头中列出能够处理的 MIME 类型，例如 image/avif 和 image/webp。源站或边缘逻辑可以据此优先选择 AVIF，其次 WebP，最后返回 JPEG 或 PNG。

请求：
GET /images/hero
Accept: image/avif,image/webp,image/png,image/*;q=0.8,*/*;q=0.5

响应：
Content-Type: image/avif
Vary: Accept

同一 URL 可能产生多种响应时，缓存必须知道选择依据。HTTP 的 Vary: Accept 用于说明响应会随着 Accept 变化。但对于 CloudFront 等 CDN，仅让源站返回 Vary 并不等于缓存键已经按期望设计；还要明确配置需要转发和纳入缓存决策的请求信息。

为什么直接把完整 Accept 头加入缓存键可能有问题？

CloudFront 默认不依据任意请求头区分缓存对象。如果把某个请求头纳入缓存策略，完整的头值会参与缓存键。不同浏览器和版本可能发送顺序、格式或附加类型不同的 Accept 值，即使它们最终都应收到 WebP，也可能形成多个缓存变体，降低命中率并增加回源。

更稳妥的设计通常是在 Viewer Request 阶段把复杂的 Accept 归一化成有限类别，例如：

• avif：包含 image/avif。

• webp：不支持 AVIF，但包含 image/webp。

• fallback：其他情况返回 JPEG 或 PNG。

随后可把归一化结果写入受控请求头或 URL 路径，并让缓存键只区分这三个值。这样既能返回兼容格式，又避免按大量原始 Accept 字符串碎片化缓存。

注意：任何修改请求路径或格式选择逻辑的 CloudFront Function、Lambda@Edge 或源站代码，都应先在测试分配中验证。错误的缓存键可能把某种格式缓存并发送给不支持它的客户端。

图片尺寸也必须进入变体设计

只有格式，没有尺寸控制，通常无法获得理想效果。可以根据业务预生成一组有限宽度，例如 320、640、960、1280 和 1920 像素，再由 srcset 与 sizes 让浏览器选择。具体档位应来自页面实际容器宽度和访问设备数据，而不是固定照搬。

如果通过查询参数请求动态尺寸，例如：

/image/product-123?width=640&quality=75&format=webp

必须规范允许值。不要让任意宽度、质量和裁切组合无限进入缓存，否则攻击者或异常客户端可以制造大量低复用变体。常见做法包括：

• 把请求宽度映射到预设档位，而不是接受任意整数。

• 限制最小与最大尺寸，并拒绝异常参数。

• 只允许受支持的格式、裁切模式和质量区间。

• 对查询参数排序和默认值进行规范化。

• 设置转换超时、并发限制和生成文件大小上限。

边缘实时转换还是预先生成？

访问量稳定、图片档位有限的网站通常适合预生成；SKU 很多、用户上传频繁或裁切规则复杂的业务可以评估按需转换。按需方案应让最终文件拥有可复用的稳定缓存键，并避免在每次命中时重新编码。

Cache-Control、Content-Type 和 Vary 应如何配合？

• Content-Type：必须与实际字节格式匹配，例如 AVIF 使用 image/avif、WebP 使用 image/webp。

• Cache-Control：带内容指纹的不可变图片可使用较长浏览器和 CDN 缓存；会被原 URL 覆盖更新的图片需要更谨慎的 TTL 与失效策略。

• Vary：同一 URL 根据 Accept 返回不同内容时，应正确反映协商维度；同时确认 CDN 的缓存策略确实区分了对应变体。

• ETag 或 Last-Modified：可帮助客户端重新验证，但不同格式应有正确且独立的验证标识。

• Content-Length：由服务端或对象存储正确返回，方便监控实际传输体积。

CloudFront 的响应头策略可以添加、删除或覆盖发送给访问者的响应头，但给查看器响应添加 Cache-Control 并不会自动改变 CloudFront 自身的缓存行为。CloudFront 的缓存 TTL 和缓存键仍应通过缓存策略及源站响应进行正确配置。

CloudFront 图片优化配置清单

1. 为图片建立独立缓存行为，避免与 HTML 或 API 共用不合适的缓存策略。

2. 确定格式策略：使用独立 URL，还是根据 Accept 协商。

3. 如果使用协商，先把浏览器能力归一化为少量格式类别。

4. 只将真正影响输出的格式、宽度、质量和裁切参数纳入缓存键。

5. 移除不影响图片内容的 Cookie、请求头和查询参数。

6. 为源图与转换结果设置明确的对象命名、TTL、失效和版本规则。

7. 限制动态参数范围，避免生成无限图片变体。

8. 确保 S3 或自定义源站不能被非预期地绕过 CDN 访问。

9. 记录格式、尺寸、缓存命中、转换耗时、错误和输出文件大小。

如何验证图片优化没有配错？

检查响应头和文件内容

curl -I \
  -H "Accept: image/avif,image/webp,*/*" \
  https://example.com/images/hero

curl -I \
  -H "Accept: image/webp,*/*" \
  https://example.com/images/hero

curl -I \
  -H "Accept: image/jpeg,*/*" \
  https://example.com/images/hero

分别确认 Content-Type、Vary、Cache-Control、缓存命中状态和文件大小。不要只相信扩展名；还应抽样下载文件并验证实际编码格式。

用浏览器检查实际选择

• 在开发者工具 Network 面板检查图片的 URL、类型、传输大小和缓存状态。

• 用不同浏览器和真实移动设备测试 AVIF、WebP 及回退路径。

• 检查高 DPR 屏幕是否收到合理尺寸，低分辨率设备是否被发送过大图片。

• 确认首屏 LCP 图片没有被错误延迟加载，并在 HTML 中可尽早发现。

• 比较 Lighthouse、PageSpeed Insights 和真实用户监测中的图片传输及 LCP 变化。

观察 CDN 和源站指标

上线后重点关注缓存命中率、回源请求、每种格式占比、图片转换错误、首个变体生成时间和数据传输量。如果文件变小但缓存命中率大幅下降，整体成本与延迟未必改善。

常见误区

误区一：把质量参数固定为同一个数字

不同编码器的质量刻度不可直接横向比较，同一数值在 AVIF、WebP 和 JPEG 中也不代表相同视觉质量。应通过代表性样本确定每种内容类型的配置。

误区二：为每一种设备生成一个尺寸

过多尺寸会增加存储、转换和缓存碎片。通常只需要覆盖主要布局断点的一组档位，由浏览器从候选集中选择。

误区三：只设置 Vary，不配置 CDN 缓存键

Vary向共享缓存说明响应的协商依据，但具体 CDN 是否、以及如何把请求头加入缓存键，仍取决于产品配置。必须用多组请求验证实际缓存行为。

误区四：按完整 User-Agent 判断格式

User-Agent 字符串复杂、易变化，还会造成大量缓存变体。优先使用标准能力信号，例如图片请求的 Accept，并将结果归一化。

误区五：转换后删除全部源图

保留受保护的高质量源图有利于以后重新编码、调整裁切或支持新格式。源图不应作为未经控制的超大文件直接提供给普通访问者。

常见问题

AVIF 一定比 WebP 更适合网站吗？

不一定。AVIF 往往有较高压缩潜力，但编码时间、具体画面质量和业务工具链也很重要。可把 AVIF 作为优先候选、WebP 作为广泛兼容的现代回退，再保留 JPEG 或 PNG 回退，并用真实样本决定。

图片 URL 是否应该带扩展名？

两种方案都可以。独立扩展名 URL 更直观，适合 picture 和预生成资源；无格式扩展名的稳定 URL 便于服务端协商，但缓存键和响应头必须配置正确。

是否需要把完整 Accept 请求头加入 CloudFront 缓存键？

通常不建议直接使用未经处理的完整值，因为不同客户端可能产生许多等价变体。更常见的做法是先归一化成 AVIF、WebP 和回退三类，再让缓存键区分有限结果。

图片已经使用 WebP，为什么网站还是很慢？

应继续检查像素尺寸、压缩质量、LCP 图片发现时间、缓存命中率、源站响应、页面图片数量和延迟加载策略。格式只是图片性能中的一个维度。

动态图片转换会不会很贵？

成本取决于请求量、生成变体数量、编码计算、存储和缓存命中率。限制参数、复用转换结果、预生成热门尺寸并监控首次生成请求，可以减少无效计算。

结论

可靠的 CDN 图片优化需要把格式、尺寸和缓存作为一个整体设计。WebP 提供广泛的现代浏览器支持，AVIF 可以进一步降低部分图片的体积，而 JPEG、PNG 或其他格式仍承担必要的回退与特定内容用途。

如果通过 Accept 自动选择格式，应使用正确的 Content-Type 和 Vary，并在 CDN 中把客户端能力归一化成有限缓存变体。与此同时，利用 picture、srcset 和 sizes 控制实际像素，限制动态转换参数，再通过真实浏览器、CDN 日志和用户性能数据验证。图片变小、缓存保持高命中且视觉质量稳定，才算真正完成优化。

参考资料

1. Google web.dev：Image performance，核查日期：2026-08-13

2. Google web.dev：Use WebP images，核查日期：2026-08-13

3. MDN：Accept header，核查日期：2026-08-13

4. MDN：HTTP content negotiation，核查日期：2026-08-13

5. AWS：Understand cache policies，核查日期：2026-08-13

6. AWS：Cache content based on request headers，核查日期：2026-08-13