技术

一个老站改版：加载从 6.2 秒压到 1.4 秒

2026 年 8 月 2 日　·　林小雨　·　约 6 分钟

山润茶油那个项目（案例在这儿）， 最花时间的不是设计，是提速。这篇文章把每一步和对应的数据变化都记下来， 如果你想自己动手，照着做也行。

先说测量方法

不讲方法的数据都是耍流氓。我们的测量条件是：

• 设备：一台 2025 年的千元安卓机（骁龙 665，4G 内存），我们专门留着测最差情况
• 网络：4G，同一地点同一时间段
• 指标：首屏可见时间（First Contentful Paint），取 5 次中位数
• 工具：Chrome DevTools + PageSpeed Insights 交叉验证

改版前：6.2 秒。这个数字意味着大多数人根本不会等到页面出来。

第一步：找出真正的元凶（6.2s → 4.1s）

打开 Network 面板一看，首页请求了 47 个资源，总共 8.9MB。其中最大的三样：

• 一张 3.1MB 的首页 banner 图（JPEG，未压缩，尺寸 4000×2600）
• 两套字体文件，加起来 1.4MB（其中一套只用在两处标题上）
• 三个插件，各自加载自己的 CSS 和 JS，页面根本用不到

我们先把那三个插件删了。它们分别是：一个在线客服（客户说从来没人点过）、 一个分享按钮组（2018 年之后没人维护）、一个统计代码（和现在用的重复）。 删完：6.2 秒 → 4.1 秒。

第二步：图片处理（4.1s → 2.3s）

这张 banner 图当初是怎么传上去的？问了客户，答"设计师给的"。 我们做的三件事：

• 按实际显示尺寸重新裁切，最大宽度 1600，移动端单独出 750 宽的图
• 全部转 WebP，压缩质量设 82。JPEG 3.1MB → WebP 176KB，肉眼看不出差别
• 首屏之外的图全部加 loading="lazy"，滚动到才加载

改完：4.1 秒 → 2.3 秒。这一步是收益最大的。

顺带说一句，我们给客户留了份拍摄清单，让他们后续自己传图前先压一下。 网站再怎么优化，也架不住后来传一张 5MB 的原图上去。

第三步：字体（2.3s → 1.9s）

两套字体里，有一套只用在 8 个页面上。我们做了两件事： 把这套字体的字符集裁剪到只保留常用 3500 字（从 780KB 降到 96KB）， 另一套保留但加上 font-display: swap，让文字先用系统字体显示出来。

改完：2.3 秒 → 1.9 秒。

第四步：服务器与缓存（1.9s → 1.4s）

• 开启 Brotli 压缩，HTML/CSS/JS 体积再降 20%
• 静态资源放到 CDN，用户从最近的节点取
• 设置强缓存：带版本号的静态文件缓存一年
• 数据库查出 3 个慢查询，加索引
• 服务器从 1 核 2G 升到 2 核 4G（一年多花 400 块，值得）

改完：1.9 秒 → 1.4 秒。

最终对比

一个容易被忽略的后续

提速不是一次性的。上线后第二个月，客户自己传了几张 2MB 的活动图上去， 首页又掉回 2.8 秒。我们后来在后台加了个上传提醒：超过 500KB 会提示压缩。

网站的速度会随着时间的推移慢慢变差，除非有人持续看着它。 这也是我们做运维托管时，每月必查的一项。

最后说一句实话

这些操作没有任何技术含量，网上教程一大把。难的是有人愿意花两天时间， 把 47 个请求一个一个看过去。大部分网站慢，不是因为技术不行，是因为没人这么干过。