优化 vvhub 微站首页加载速度：从图片缓存到格式压缩的实战记录

原创已于 2025-03-16 10:08:21 修改 · 993 阅读

25 ·

CC 4.0 BY-SA版权

文章标签：

#缓存

于 2025-03-16 09:52:26 首次发布

开发技巧专栏收录该内容

7 篇文章

订阅专栏

在开发 vvhub 微站项目的过程中，我遇到了一个棘手的问题：首页图片加载速度过慢。作为一个追求用户体验的项目，加载慢不仅影响首屏渲染，还可能导致用户流失。于是，我开始了一段从代码优化到服务器升级，再到图片格式调整的探索之旅。以下是我的问题分析与解决过程，希望对遇到类似问题的开发者有所启发。

问题初现：首页图片加载慢

项目上线后，我发现首页的图片加载时间明显偏长，尤其是首次访问时，用户需要等待数秒才能看到完整内容。我的第一反应是优化代码和配置，毕竟服务器的基础带宽（5M，峰值流量 750KB/s）有限，我希望在不改变硬件条件的前提下，先从技术层面入手。

通过查阅资料和借助 AI 分析，我了解到可以在 Nginx 上配置图片缓存，以减少重复请求的加载时间。于是，我在 Nginx 配置文件中添加了以下优化：

# 专门处理图片请求的 location
location /api/file/getResource {
    proxy_set_header Accept-Encoding "gzip";
    gzip on;
    gzip_min_length 1k;
    gzip_buffers 4 16k;
    gzip_comp_level 3;  # 压缩级别，1-9，数字越大压缩越好但 CPU 消耗更高
    gzip_types image/jpeg image/gif image/png image/webp;
    gzip_vary on;

    proxy_pass http://124.243.172.201:7071/file/getResource;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

# 静态图片资源缓存
location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$ {
    expires 30d;
    error_log /dev/null;
    access_log /dev/null;
}

这些配置启用了 Gzip 压缩，针对 /api/file/getResource 接口返回的图片资源进行压缩。如果首页图片通过这个接口获取，Gzip 可以减小图片传输的数据量，从而缩短下载时间。并设置了 30 天的缓存时间，浏览器会在首次加载后将图片存储在本地缓存中，后续请求直接从缓存读取。理论上应该能提升加载速度。然而，实际效果并不理想。首次加载仍然很慢，因为缓存只有在第二次访问时才会生效，而用户首次打开首页的体验依然糟糕。更何况，模拟慢速 4G 网络（F12 开发者工具）时，加载时间依然让人抓狂。

带宽瓶颈：从 5M 到 30M 的升级

在优化图片加载的同时，我还注意到视频播放也有卡顿问题。结合服务器带宽只有 5M 的现实，我意识到这可能是根本限制。对于一个包含视频和图片的微站，5M 带宽（约 625KB/s 的理论峰值）远远不够。理论上，至少需要 15M 带宽（约 1.875MB/s）才能满足需求。

于是，我将服务器升级到了一台海外机器，带宽拉到 30M。果不其然，视频播放变得流畅了，峰值流量也提升到了 4.75MB/s。然而，首页图片加载的问题依然存在，尤其是在用户网速较差的情况下，加载时间仍然不理想。这让我开始怀疑问题是否出在图片本身。

灵感来源：B 站的 AVIF 格式

为了寻找更优解，我打开了 B 站的首页进行研究。B 站首页几乎是“秒开”，即使在慢速网络下也能迅速加载。带着好奇，我打开 F12 开发者工具，查看图片资源，发现它们采用了 AVIF 格式。

什么是 AVIF？
AVIF（AV1 Image File Format）是一种基于 AV1 视频编码的图片格式，具有极高的压缩效率。它能在保证画质的前提下大幅减小文件体积，是 Web 性能优化的新宠。

我注意到，B 站的每张图片大小仅约 10KB，尺寸虽小但清晰度依然很高。相比之下，我的项目首页使用的却是 PNG 格式，单张图片动辄 3-5MB——这相当于 200 张 AVIF 图片的体积！问题根源找到了：图片文件过大是加载慢的罪魁祸首。
在这里插入图片描述

解决方案：前端压缩与 WebP 格式的选择

由于项目中图片压缩逻辑是在前端实现的，我和前端同学研究了现代图片格式的优化方案。受到 B 站 AVIF 格式的启发，我对比了 WebP 和 AVIF，最终选择了 WebP。以下是两者的对比：

特性	WebP	AVIF
推出时间	2010 年，由 Google 开发	2019 年，由 Alliance for Open Media 开发
压缩效率	高，比 JPEG 和 PNG 更优	更高，比 WebP 再小 20%-50%
画质表现	中等压缩下良好，低比特率下失真较明显	低比特率下仍保持较高画质
文件大小	比 PNG 小，通常比 AVIF 略大	极小（如 B 站图片仅 10KB）
浏览器兼容性	广泛支持（95%+ 用户覆盖率）	支持较新（80%-85% 用户覆盖率）
编码/解码速度	较快	较慢，计算成本高

为什么选 WebP？

AVIF 的压缩效率令人惊艳，但它的浏览器兼容性尚未达到 WebP 的水平（截至 2025 年 3 月，Safari 等部分旧版浏览器仍不支持）。考虑到 vvhub 微站需要服务尽可能多的用户，我选择了兼容性更强的 WebP。此外，WebP 的工具支持更成熟，编码速度也更快，与项目现有技术栈契合度更高。在带宽升级到 30M 的情况下，WebP 已足以实现“秒开”目标。

具体实现上，我们使用了 vue-cropper 组件对图片进行裁剪和压缩，核心代码如下：

<VueCropper
  ref="cropperRef"
  :img="sourceImage"
  outputType="webp"
  :outputSize="0.8"  <!-- 压缩质量设为 80% -->
  :autoCrop="true"
  :autoCropWidth="props.cutWidth"
  :autoCropHeight="Math.round(props.cutWidth * props.scale)"
  :fixed="true"
  :fixedNumber="[1, props.scale]"
  :centerBox="true"
/>

经过测试，WebP 格式将图片体积降低到原来的 1/10 甚至更小。例如，5MB 的 PNG 文件压缩后仅剩几百 KB，画质依然可接受。首页加载时间大幅缩短，用户体验显著提升。

在这里插入图片描述