JPG 转 WebP 值不值得：画质、体积与兼容性的决策和实操
「要不要把站里的 JPG 全转成 WebP」是性能优化清单上最常见也最容易做错的一项。WebP 通常能比同画质 JPG 小 25-35%,但「全转」之前有三个决策问题要先回答：浏览器兼容还剩多少缺口、你的 JPG 里有多少是照片多少是图形、转换的画质参数选多少。本文给出判断标准和实操路径；急着转换的可以直接用 JPG 转 WebP 工具，在浏览器本地完成，图片不上传。
先回答三个决策问题
一、你的受众还用不用老 Safari？
WebP 的全浏览器支持从 2020 年 10 月（Safari 14）起达成，CanIUse 口径至今（2026）覆盖率 97%+。缺口主要是：老款 iOS 14 以下设备、部分国产浏览器内核（占比极小但存在）、以及某些老旧的邮件客户端。判断口径很简单：看你的统计里 iOS 14 以下与 IE 的占比，低于 1% 就可以放心全量；仍有明显占比的场景用 <picture> 双源兜底：
<picture>
<source srcset="photo.webp" type="image/webp">
<img src="photo.jpg" alt="...">
</picture>
二、图片是照片还是图形？
WebP 有损压缩对照片类（连续色调、噪点自然）收益最大，25-35% 的体积缩减几乎无感；对锐利图形类（截图、图标、文字边缘），有损 WebP 在低 quality 下会出现振铃伪影（边缘泛起波纹），反而 PNG 或无损 WebP 更合适。速查：
| 图片类型 | 首选格式 | 理由 |
|---|---|---|
| 照片、渐变背景 | 有损 WebP (q75-85) | 体积收益最大，伪影不可见 |
| 截图、UI、含文字 | PNG 或无损 WebP | 锐边不能容忍振铃 |
| 透明通道照片 | WebP（Alpha） | JPG 不支持透明 |
| 动图 | WebP 动画 / MP4 | 替代 GIF 体积差一个数量级 |
三、quality 参数选多少？
canvas 编码路径里 quality 是 0-1 的浮点数（0.75-0.85 是照片的甜区）。不要用默认值——各引擎默认不一，结果不可比。同一张图建议 q70/q80/q90 三档各转一次，肉眼对比后取「看不出差异的最低档」；要批量跑出结论，就固定一组图做 A/B 体积对比。
实操：浏览器本地转换
单个文件或少量文件，没必要上命令行——打开 JPG 转 WebP 工具：
- 拖入
.jpg/.jpeg文件（支持批量）； - 调整画质滑杆（默认 0.8，照片甜区）；
- 下载转换后的
.webp。
全程在你机器上跑——解码、canvas 重编码、打包下载都在浏览器进程里完成，图片内容不离开本机。反向需求（别人发来 WebP 你要塞进只认 JPG 的系统）用 WebP 转 JPG；PNG 源走 PNG 转 WebP；HEIC（iPhone 原图）先走 HEIC 转 JPG 再进 WebP。批量尺寸调整配合图片压缩工具可以一次把「转格式 + 限宽 + 控体积」做完。
命令行批量（站点迁移场景）
存量几百上千张图，用 cwebp 批量：
# 目录下全部 JPG → WebP，q80，保留原文件
for f in *.jpg; do cwebp -q 80 "$f" -o "${f%.jpg}.webp"; done
CI 里常见的进阶做法是 sharp（Node）或 vips（CLI 底层），支持按宽度分层输出响应式 srcset。转换后记得抽查 3-5 张放大看细节——批量参数对个别图（高对比度文字截图混在照片里）可能翻车。
常见坑
- EXIF 方向丢失/错乱：某些转换管线输出的 WebP 变成横躺的——原因是解码时没读 EXIF orientation。本站工具在解码阶段显式传
imageOrientation: 'from-image'，旋转信息在重编码前就已应用到像素，输出不再依赖查看器理解 EXIF； - 体积不减反增：本来就很小的 JPG（小于 10KB）或已高度压缩的图，转 WebP 可能持平甚至更大。转换前对比一下输出体积，收益不足 10% 的图不值得换格式（双份缓存反而浪费）；
- PWA/离线包里的 WebP：部分老 Service Worker 缓存实现对 WebP MIME 处理不全，离线场景要实测；
- 有损链叠加：JPG→WebP→再压缩，每次有损重编码都在累积损伤。存量迁移只转一次，源文件留档。
实现注记 / Implementer's note
站内七个格式转换器（jpg/png/webp/heic/svg 互转）共享同一个引擎组件，每个转换器只是「目标 MIME + 扩展名」的配置实例——这保证了 EXIF 方向处理、批量逻辑、错误提示在七个工具间行为一致，修一处全修。引擎用 createImageBitmap 解码并显式声明 imageOrientation: 'from-image'（尊重 EXIF，防横竖颠倒），不支持的旧引擎回退 <img> 元素路径。编码走 canvas.toBlob，quality 仅对有损格式生效——PNG 目标显式传 undefined 走无损，这是规范里「传了 quality 反而可能被有损化」的细节。HEIC 解码依赖 heic2any 的 wasm（约 1.5MB），动态 import——只有真正打开 HEIC 转换页的用户才下载它，其他六个转换器不为它付体积。
FAQ
WebP 比 JPG 到底小多少？
同主观画质下通常 25-35%；q80 WebP 对比 q80 JPG 的典型收益是照片类 30% 左右。但小图（小于 10KB）可能持平，先试再批量。
转 WebP 会影响 SEO 吗？
格式本身不影响排名，影响的加载速度受益于它——Core Web Vitals（尤其 LCP）变好是正向信号。用 <picture> 兜底时 img 的 alt 原样保留即可。
Apple 生态还用特殊处理吗？
2026 年不需要：Safari 14+（2020-10）全支持 WebP，iOS 系统相册也能直接打开。只有维护老设备兼容列表的产品才需要双源。
无损 WebP 和 PNG 选谁？
无损 WebP 比 PNG 小 20-25%，兼容性同 WebP 全景。如果 <picture> 兜底已就绪，图形类可以统一无损 WebP；没有兜底就留 PNG，省心。
这篇决策笔记来自 ToolVault 工具匣图片转换矩阵的实现过程，EXIF 方向与双引擎回退都是开发中实测过的取舍。
补充注记
七个转换器收敛到一个引擎组件的动机是维护成本：早期两三个转换器各写各的，EXIF 方向修复上线时漏改了一个，用户拿横图反馈才暴露——统一引擎后这类修复天然全量生效。「配置实例化工具」的模式后来也用到了图片矩阵之外的组件族上。