Levi Blog

1. 先统一目标：你要优化什么指标#

图片优化不是为了“文件小”，而是为了真实体验：

• LCP：首屏大图加载速度
• CLS：图片尺寸占位是否稳定
• TTFB 之后的首屏渲染路径
• CDN 出口流量成本

如果你在做商业站点，还要考虑：

• 构建时间是否可控
• 图片处理链路是否稳定
• 运维复杂度是否可接受

2. WebP 和 AVIF 的核心差异#

2.1 压缩率#

• 在同等主观画质下，AVIF 通常比 WebP 更小。
• 但不同图像类型差异很大：
  • 照片类：AVIF 优势通常更明显。
  • 图标/平面插画：WebP 已经足够优秀。

结论：AVIF 往往更省带宽，但不是所有图都必须 AVIF。

2.2 编码与构建成本#

• WebP 编码速度通常更快，CI/CD 压力更低。
• AVIF 编码更耗 CPU，尤其在批量处理大图时，构建耗时会显著增长。

如果你的项目每日多次构建，且图片频繁更新，要优先评估 AVIF 带来的构建成本。

2.3 浏览器兼容与回退策略#

现代浏览器对 AVIF 和 WebP 支持已经很完整，但工程上仍应保留回退方案。

推荐做法：AVIF -> WebP -> JPG/PNG 三层回退，使用 <picture>。

1
<picture>
2
  <source srcset="/img/hero.avif" type="image/avif">
3
  <source srcset="/img/hero.webp" type="image/webp">
4
  <img
5
    src="/img/hero.jpg"
6
    alt="站点首页主视觉"
7
    width="1200"
8
    height="630"
9
    loading="eager"
10
    decoding="async"
11
  >
12
</picture>

这段代码同时解决两件事：

• 让高能力浏览器拿到更小资源
• 让不支持新格式的环境稳定降级

3. 什么时候选 WebP，什么时候优先 AVIF#

你可以直接用下面这套决策逻辑：

• 页面首屏关键图（Hero 图）
  • 首选 AVIF（质量可接受前提下）
  • 同时保留 WebP 和 JPG 回退
• 中小尺寸内容图
  • WebP 作为默认选项，性价比高
• 后台管理系统或内部工具
  • 优先 WebP，降低构建和维护复杂度
• 用户上传图片量很大
  • 先统一 WebP，再对热点资源追加 AVIF

工程目标不是“全站 AVIF”，而是“在收益最高的位置用 AVIF”。

4. 实战：用 Sharp 批量生成多格式#

如果你是 Node 项目，Sharp 是最稳的路线之一。

1
npm i -D sharp

示例脚本（scripts/image-build.mjs）：

1
import fs from 'node:fs/promises';
2
import path from 'node:path';
3
import sharp from 'sharp';
4

5
const inputDir = 'img/source';
6
const outputDir = 'img/optimized';
7

8
await fs.mkdir(outputDir, { recursive: true });
9
const files = await fs.readdir(inputDir);
10

11
for (const file of files) {
12
  const inputPath = path.join(inputDir, file);
13
  const ext = path.extname(file).toLowerCase();
14
  const base = path.basename(file, ext);
15

16
  if (!['.jpg', '.jpeg', '.png'].includes(ext)) continue;
17

18
  const image = sharp(inputPath).rotate();
19

20
  await image
21
    .clone()
22
    .webp({ quality: 78 })
23
    .toFile(path.join(outputDir, `${base}.webp`));
24

25
  await image
26
    .clone()
27
    .avif({ quality: 52, effort: 4 })
28
    .toFile(path.join(outputDir, `${base}.avif`));
29

30
  await image
31
    .clone()
32
    .jpeg({ quality: 82, mozjpeg: true })
33
    .toFile(path.join(outputDir, `${base}.jpg`));
34
}
35

36
console.log('image build done');

这份参数不是绝对标准，但适合大多数博客/内容站作为初始值。

5. 避免“图片变小但体验变差”#

以下是常见反模式：

1. 只压缩，不裁剪： 你把 3840px 大图压成 AVIF，但页面只显示 800px，仍然浪费带宽。
2. 忽略尺寸占位： 没有写 width/height，导致图片加载时页面抖动（CLS 上升）。
3. 首屏图片懒加载： 首屏主图设置 loading="lazy" 会拖慢 LCP。
4. 一刀切质量参数： 所有图统一质量值，可能造成局部明显糊图。

正确做法是：先区分场景，再按场景设置参数。

6. CDN 与边缘优化策略#

如果你使用 Cloudflare、CloudFront、Fastly 等 CDN，可以结合以下策略：

• 根据 Accept 头自动协商格式
• 首屏关键图做多尺寸版本（srcset）
• 对热门资源设置更长缓存周期
• 对低访问图使用更保守编码策略，减少构建成本

这能把“构建侧压力”与“传输侧收益”做平衡。

7. 一套可执行的上线流程#

1. 选 3 张高流量页面图片作为试点。
2. 生成 AVIF/WebP/JPG 三格式并接入 <picture>。
3. 对比上线前后 7 天数据：
   • 页面 LCP
   • 图片总流量
   • 错误率和兼容反馈
4. 如果结果稳定，再扩展到其他页面。

不要一次性重构整个站点，先用小样本跑通闭环。

8. 给博客站点的简化建议#

如果你维护的是 Jekyll 或轻量博客：

• 封面图和正文大图：三格式回退
• 小图标：优先 SVG
• 截图类教程图：优先 WebP（文字边缘更清晰）
• 每篇文章控制图片总量，避免“图太多导致正文价值稀释”

总结#

WebP 和 AVIF 不是对立关系，而是组合关系。

• WebP：稳定、快、够用，适合默认策略。
• AVIF：体积优势明显，适合关键资源和高价值页面。

先从核心页面做增量优化，再逐步扩展，才是长期可维护的性能策略。