在不损失画质的前提下发布更轻量的图片

图片通常是页面上最“重”的部分，因此也是性能优化里最大、最容易拿下的一分。目标不是“不惜代价地变小”——而是在最终呈现的屏幕上依然好看的前提下，做到最小文件。下面这套工作流能帮你达成目标，而不必对每次导出都靠肉眼把关。

先调整尺寸，再压缩

最大的一笔节省通常来自<b>尺寸</b>，而不是编解码器。一张 4000px 的大图被塞进 800px 的展示位，在压缩还没开始之前就已经浪费了约 96% 的像素。先确定真实的显示尺寸，考虑高 DPR 屏幕的需求（对大多数照片来说 2× 就足够了），先把图缩小到位。压缩一张尺寸合适的图片，后面每一步要做的事都会少很多。

为不同场景选对格式

照片：用 AVIF 或 WebP，如果还需要兼容性就配上 JPEG 回退。平面 UI、Logo 和截图：用无损 PNG 或 WebP。不要发布照片的 PNG，也不要发布截图的 JPEG——两者都是用错了工具，既费字节<i>又</i>损画质。拿不准的时候，两种方式都编码一遍，留下胜出的那个。

设定感知画质目标

“质量 80”在不同编码器之间含义各不相同，所以应该以<b>感知</b>结果为目标，而不是盯着某个魔法数字。对大多数照片来说，SSIMULACRA2 分数在 80–90 左右基本可视为无损；低于约 70 时，你会开始在渐变和肤色上看出差异。设定一个下限，让编码器去达成它，你就能让整个素材库保持一致的画质，而不用逐个文件靠猜。

# 先缩放到显示尺寸，再以质量下限进行转换
imageforge hero.png --resize 1600 --convert avif --quality 82
imageforge ./gallery/*.jpg --convert webp --quality 80 --recursive

让它自动化

只有运行起来枯燥无趣，一套工作流才会真正被坚持下来。批量处理整个文件夹，保留原始文件不变，让工具报告节省的空间，这样你才能信任结果。关键在于让“更轻量”成为默认路径，而不是有人在上线前容易忘记的手动杂活。

要发布的是“依然好看的最小文件”——而不是“最小的文件”。这一字之差就是整个工作的核心。

衡量，而不是猜测

不要只看文件大小，要检查实际节省的空间和实际画质，把这个闭环走完。一个体积小了 90% 但看起来明显变差的文件不算胜利；一个小了 60% 但视觉上毫无差别的文件才算。同时追踪这两个指标，你就能放心地把设置往前推，而不是一味保守。