做博客和静态站点时，图片往往是最容易失控的资源。页面慢、首屏重、仓库体积膨胀，很多时候都不是代码问题，而是图片没有处理好。
这篇文章整理一套够用的思路：先压缩，再转换，再检查颜色与元数据。
为什么优先考虑 AVIF
和传统 PNG、JPEG 相比，AVIF 往往能在相近画质下把体积压得更小，尤其适合：
- 博客封面图
- 截图类配图
- 色块明显的插画或 UI 资源
但它也不是银弹。兼容性、编码耗时和调试成本都比 JPEG/WebP 更高，所以更适合构建阶段统一处理，而不是手工到处转。
在线压缩适合什么场景
如果只是偶尔处理少量素材，在线压缩工具足够快。它适合：
- 临时处理一两张封面图
- 不想本地安装编码工具
- 对批处理和脚本化没有要求
缺点也很明显：流程不可复现，参数不可追踪，不适合长期维护的内容站点。
用 avifenc 把 PNG 转成 AVIF
本地命令行的好处是稳定、可复用、可写进脚本。
avifenc --qcolor 85 --qalpha 85 --speed 0 --yuv 420 example.png example.avif这条命令可以这样理解：
--qcolor 85：颜色质量--qalpha 85：透明通道质量--speed 0：最慢，但通常压缩效果最好--yuv 420：较常见的采样方式，兼顾体积与兼容性
如果素材是插画、界面截图或带透明背景的图片，建议先用少量样本测试，再决定是否统一用同一组参数。
清理元数据
图片里常常带有拍摄信息、软件信息或其他无关元数据。对博客站点来说，这些内容通常没有保留价值。
exiftool -all:all= example.avif清理元数据能进一步减小体积，但这里有一个常见坑：有些图片的颜色配置文件也可能被一起清掉，导致显示异常。
颜色配置文件问题
如果清理元数据后图片出现偏色、发灰或干脆无法正常显示，可以重新指定颜色配置：
magick example.avif -profile "/System/Library/ColorSync/Profiles/sRGB Profile.icc" fixed.avif这个步骤的意义是把图片重新映射到更通用的 sRGB 配置，减少不同设备上的显示偏差。
一套更稳妥的处理顺序
我更推荐下面这个顺序：
- 先保留原图，永远不要在唯一源文件上反复覆盖。
- 用
avifenc做格式转换和第一轮压缩。 - 检查图片是否存在偏色、透明边缘异常或锐化过度。
- 再视情况清理元数据。
- 最后在页面里验证实际显示效果，而不是只看文件大小。
什么时候不要强上 AVIF
下面几种情况，未必值得转换：
- 素材本来就很小
- 图片需要频繁被第三方工具再次编辑
- 你的构建链路暂时没有稳定处理 AVIF 的能力
优化的目标不是“所有图片都用最新格式”，而是“在可维护前提下，让页面更轻”。
结语
图片优化没有神秘技巧，核心就是三件事：控制尺寸、选择合适格式、避免无意义元数据。只要把这套流程固定下来，博客的加载体验通常会立刻改善一截。