打开一个普通网页，网络传输里占比最大的往往不是 JS，也不是 CSS，而是图片。前端图片优化 正是性价比最高的一处性能杠杆：选对格式、压对质量、用对交付方式，经常能把首屏体积砍掉一半以上。而在众多格式里，WebP 与 AVIF 是当下最值得投入的两种现代图片格式。本文从原理、选型到构建期压缩与 CDN 缓存，手把手把图片优化落到生产。
为什么图片是性能的第一权重
HTTP Archive 的长期统计显示，移动端页面平均传输大小中，图片常年占据六成以上。相比把一段 JS 从 200KB 压到 150KB，把一张 800KB 的首图换成 90KB 的 AVIF，对 Largest Contentful Paint（LCP）的改善要直接得多。这也是为什么在做 前端性能优化 时，首屏图片永远是优先处理对象。
但图片优化的难点不在”压”，而在”平衡”：压缩过头，肉眼可见的糊；压得不够，体积又下不来。WebP 和 AVIF 之所以被推崇，是因为它们在”更小体积”和”几乎无损观感”之间，比传统的 JPEG、PNG 做得好得多。
WebP 与 AVIF 到底是什么
WebP：谷歌推出的折中方案
WebP 由 Google 在 2010 年推出，同时支持有损、无损、透明（alpha）和动图（替代 GIF）。它的有损算法基于 VP8 帧内编码，无损则基于预测变换。最大优势是兼容性广：从 Chrome、Edge、Firefox 到 Safari 14+ 都已支持，是”稳妥可大规模使用”的现代格式。
AVIF：来自视频编码的狠角色
AVIF 基于 AV1 视频帧的帧内编码，是 Alliance for Open Media（谷歌、网飞、亚马逊等联合）推出的开放格式。它的压缩效率比 WebP 又高了一截——同等观感下常常能再小 20%–30%，尤其擅长处理渐变、天空、暗部等 JPEG 容易出块的地方。缺点是编码较慢、旧浏览器（如 IE 和老版 Safari）不支持，需要通过 <picture> 做回退。
体积与质量对比：到底能小多少
| 格式 | 透明/动图 | 相对 JPEG 体积 | 编码速度 | 解码开销 |
|---|---|---|---|---|
| JPEG | 不支持 | 基准 100% | 快 | 低 |
| PNG | 支持透明 | 通常更大 | 快 | 低 |
| WebP | 均支持 | 约 60%–75% | 中 | 低 |
| AVIF | 均支持 | 约 45%–60% | 慢 | 中 |
需要强调：上面的比例是”同等主观观感”下的典型区间，真实数字取决于图片内容。风景照、插画这类平滑区域多的图，AVIF 优势最大；而本身就是小图标、线条图的 PNG，转成 WebP 往往更有意义（PNG 转 WebP 常能减体 30% 以上）。
选型决策：什么时候用谁
| 场景 | 推荐格式 | 理由 |
|---|---|---|
| 需要兼容老浏览器的主图 | WebP + JPEG 回退 | 兼容面最广，风险最低 |
| 追求极致体积的首屏大图 | AVIF + WebP 回退 | 体积最小，LCP 收益最大 |
| 图标 / 线条 / 需要像素级清晰 | SVG（矢量） | 无限缩放不失真，体积极小 |
| 需要透明的小图 | WebP | 比 PNG 更小且保透明 |
| 动图 | AVIF / WebP 动图 | 替代 GIF，体积骤降 |
结论很直接：新项目应该把”AVIF 为主、WebP 兜底、JPEG/PNG 作最后回退”作为默认策略；对兼容性敏感的存量页面，先用 WebP 替换 PNG/JPEG 就能拿到第一波收益，再逐步引入 AVIF。
用 <picture> 实现格式回退
浏览器并不都能识别 AVIF，所以要用 <picture> 让现代浏览器自动挑最优格式，老浏览器退回 JPEG。关键在于 srcset 里按格式排列，浏览器会选用它支持的第一种。
<picture>
<!-- 现代浏览器优先用 AVIF -->
<source type="image/avif" srcset="hero.avif">
<!-- 不支持 AVIF 的用 WebP -->
<source type="image/webp" srcset="hero.webp">
<!-- 兜底 JPEG，所有浏览器都认识 -->
<img src="hero.jpg" alt="产品主视觉" width="1200" height="630"
loading="lazy" decoding="async">
</picture>注意 <img> 上仍要写 src 和 alt、width/height，这样既保证兜底正确，也能提前占位避免 浏览器渲染时的重排重绘。配合 前端懒加载 的 loading="lazy"，非首屏图片还能延后加载。
命令行压缩：cwebp 与 avifenc
不想引入构建工具时，命令行最直接。WebP 官方工具 cwebp、AVIF 工具 avifenc（来自 libavif）都能在本地批量处理。
# WebP 有损，质量 80（0-100），通常 75-85 是甜区
cwebp -q 82 photo.jpg -o photo.webp
# WebP 无损
cwebp -lossless photo.png -o photo.webp
# AVIF 有损，CRF 越低越清晰（常用 28-34），speed 越高越快
avifenc --min 28 --max 28 --speed 6 photo.jpg photo.avif
# 批量把目录下 jpg 转成 avif
for f in *.jpg; do avifenc --min 30 --max 30 "$f" "${f%.jpg}.avif"; done质量参数的甜区值得多试几张：WebP 的 -q 82、AVIF 的 CRF 30 左右，在大多数照片上肉眼几乎无差异，体积却能砍掉一大块。切忌”一刀切”——插画、文字截图对压缩更敏感，应单独调高保真度。
在 Node 构建期自动压缩：sharp
真正可复现的方案是在构建期自动产出多格式。Node 生态里的 sharp（底层 libvips）一行就能同时生成 AVIF 和 WebP，非常适合接进静态站或 SSR 框架。这与 Vite 前端构建 的工程化思路一脉相承。
const sharp = require('sharp');
const fs = require('fs');
async function optimize(input, name) {
const img = sharp(input);
// AVIF：质量 55，近乎无损观感下体积最小
await img.clone().avif({ quality: 55 }).toFile(`dist/${name}.avif`);
// WebP：质量 82 作兜底
await img.clone().webp({ quality: 82 }).toFile(`dist/${name}.webp`);
// 同时保留一张压缩后的 JPEG 兜底
await img.clone().jpeg({ quality: 80, mozjpeg: true })
.toFile(`dist/${name}.jpg`);
}
optimize('src/hero.png', 'hero');接进 Vite：构建产物自动多格式
若用 Vite 打包，可以借助 vite-plugin-imagetools 等插件，在 import 图片时自动产出 AVIF/WebP 并提供 srcset。这样业务代码里依然只写一张图，工具链负责生成所有格式与宽度。
// vite.config.js
import { imagetools } from 'vite-imagetools';
export default {
plugins: [imagetools()],
};
// 业务代码：导入时会拿到多格式元数据
import hero from './hero.jpg?w=1200;800;400&format=avif;webp&srcset';
// hero 已包含 avif/webp 的 srcset，直接塞进 <picture> 即可把图片格式决策交给构建期，好处是团队里没人需要手动记”这张图该转什么”，CI 里跑一次就全站统一。
响应式图片：让小屏少下载
光压格式还不够，手机不该下载 2000px 宽的桌面图。用 srcset + sizes 让浏览器按设备选宽度，再叠加多格式，体积可以再降一截。
<picture>
<source type="image/avif"
srcset="hero-400.avif 400w, hero-800.avif 800w, hero-1200.avif 1200w"
sizes="(max-width: 600px) 400px, (max-width: 1000px) 800px, 1200px">
<source type="image/webp"
srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w"
sizes="(max-width: 600px) 400px, (max-width: 1000px) 800px, 1200px">
<img src="hero-800.jpg" alt="响应式主图" width="1200" height="630">
</picture>这正是 Vue3 组合式 API 这类框架做组件化图片组件时该封装的能力：一个 <AppImage> 组件，对外只接 src 和 alt，内部产出完整 <picture> + srcset。
交付层：CDN 与 Nginx 缓存
图片生成多格式后，要让它们被高效缓存。在 Nginx 反向代理 或 CDN 上给图片设长缓存（含哈希文件名 + Cache-Control: immutable），能让回源压力骤降。对动态 Accept 头协商格式的网关，务必确保 AVIF/WebP 的 Vary: Accept 正确，否则可能把 AVIF 错发给不支持的浏览器。
# Nginx：图片长缓存 + 不可变
location ~* \.(avif|webp|jpg|png|svg)$ {
expires 1y;
add_header Cache-Control "public, immutable";
# 按浏览器 Accept 协商格式时务必带上
add_header Vary Accept;
}把优化带进 CI：别让体积回弹
图片优化最怕”一次做完，三个月后又变胖”。把它写进 GitHub Actions 自动化 流水线，提交时自动扫描新增图片、压缩并对比体积，超阈值就报错，能长期守住成果。编辑同学在 VS Code 里预览时也更容易发现异常大图。
# 简单校验：提交里若有超过 200KB 的未压缩 jpg/png 就阻断
name: image-budget
on: [pull_request]
jobs:
check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Find oversized images
run: |
found=$(find assets -type f \( -name '*.jpg' -o -name '*.png' \) -size +200k)
if [ -n "$found" ]; then
echo "以下图片超过 200KB，请先转 WebP/AVIF: $found"
exit 1
fi与无障碍、SSR 的配合
优化不是孤立的：所有 <img> 必须有有意义且非”图片1″的 alt，否则再小也过不了 前端可访问性 检查；而在 前端水合与 SSR 场景下，务必在服务端就把最终 src 算好，避免客户端二次重排导致图片闪烁。
常见坑与排障
| 现象 | 根因 | 解决 |
|---|---|---|
| 老 Safari 显示裂图 | 只出了 AVIF 没有回退 | 用 <picture> 补 WebP/JPEG 回退 |
| AVIF 体积反而更大 | 小图或线条图不适合 | 改用 WebP 或 SVG |
| CDN 把 AVIF 错发老浏览器 | 没设 Vary: Accept | 协商格式时加 Vary: Accept |
| 转码后文字发虚 | 有损压太狠 | 文字截图用无损或提高质量参数 |
| CI 里 avifenc 很慢 | 默认 speed 太低 | 提 speed 到 6-8 或仅首屏图转 AVIF |
总结
前端图片优化的核心动作就三件：选对格式（AVIF 主攻、WebP 兜底、JPEG/PNG 收尾）、压对质量（照片甜区 WebP q82 / AVIF CRF30 左右）、用对交付（<picture> 回退 + 响应式 srcset + 长缓存）。把它从”人工一次性处理”升级成”构建工具 自动产出 + CI 体积门禁“，就能让首屏稳定变轻、LCP 持续可控。对于任何一个追求性能的现代站点，这都是一个投入产出比极高、且几乎零风险的优化起点。
