博客图片优化记录：关于画质与加载开销的权衡

在完善博客图片存储方案的过程中，我注意到一个现象：直接放在本地并由 Hugo 生成的图片，在视觉上存在明显的模糊感。这促使我查阅了相关的处理流程。

1. 默认配置的局限性

通过查阅文档，我发现 Hugo 的默认图像处理参数更倾向于“兼容性”。这套标准大约设定于十年前，当时的首要目标是在极差的网络环境下保证图片能被加载出来。但在现在的显示设备下，这种为了节省流量而牺牲画质的做法已经显得有些落后。

直接看 Hugo 的源代码和文档。

• 官方默认值：根据 Hugo 官方文档（Image Processing Config），如果你不写任何配置，默认的 JPEG 质量（Quality）确实是 75。

• 官方默认滤镜：默认的缩放滤镜（Resample Filter）是 Box（盒子算法）。

  • 注：Box 是所有算法里计算最快、但画质最粗糙的；而 Lanczos 是计算最慢、但画质最细腻的。

依据来源：Configure imaging

2. 尝试调整处理方式

为了改善画质，我修改了配置文件，将图片缩放的算法更换为 Lanczos，压缩率改为90%。

在hugo.yaml中加入这段配置

1
2
3
4
5
6
7
8
9

imaging:
  # 质量调整为 90（消除文字截图的噪点）
  quality: 90
  
  # 采样过滤器使用 Lanczos（让缩放后的图片更锐利清晰）
  resampleFilter: "lanczos"
  
  # 如果图片是 PNG，这行确保 Hugo 处理后依然保持高质量
  hint: "photo"

• 处理逻辑：这种算法在缩放图片时会进行更多的数学计算，以保留物体边缘的清晰度。

• 资源置换：它的逻辑很简单——在生成网页时，由我的电脑提前完成复杂的运算。这样，图片在传到服务器并被访客打开时，就已经是处理好的、体积小且清晰的状态。

默认配置 vs Lanczos 算法

在Unsplash找了一张高清图片放在博客上进行配置变更前后对比，附上放大后的对比图

据说JPEG对红色不友好，其实这个对比图效果还不明显，这是实拍图，有些软件绘制的有弧度的红色图形效果最明显，锯齿一下子全没了，但是只是没有保留之前的图片，懒得回退了，这里就不放了。

3. 过程中的反馈

应用新配置后，电脑的反馈非常直接：由于计算量增大，处理器负载瞬间升高，散热风扇也开始全速运转，花了7.5秒才构建好。

起初这让我产生了一些疑虑，担心操作是否得当。但从逻辑上讲，这是一种合理的交换。我在本地多消耗一些电量和时间，换取的是最终生成的图片在网络上传输时更轻快。

4. 最终的数据测试

为了确认这套操作的实际效果，我使用 Google PageSpeed 对部署后的站点进行了测试：

• 加载时的资源占用 (TBT)：0 毫秒。这说明访客的设备在打开页面时，完全不需要为图片处理额外费劲。

• 页面稳定性 (CLS)：0。加载过程中没有出现文字跳动。

• 性能评分：移动端为 84，桌面端达到了 90。

• 规范性 (Best Practices)：拿到了 100 分 的满分。

虽然因为免费服务器的物理延迟，首屏加载时间（LCP）还有提升空间，但就图片本身和代码结构而言，目前的方案已经达到了我预期的平衡点。