这是一个制造业客户的官网，上线两年，首页加载 4.2 秒，移动端 4G 环境下更糟。我们花了两周把它压到 1.1 秒，过程写下来供参考。
先测量，别凭感觉优化
第一步不是改代码，是拿到真实数据。我们看了三个来源：
- 服务端访问日志里，真实用户的平均响应时间
- 性能测试工具给出的瀑布图，看每个资源的加载顺序和耗时
- 移动端实测，用一台中端安卓机在 4G 网络下打开
结论是：服务器响应只要 180 毫秒，问题几乎全在前端。
最大的问题往往不在图片
很多人以为慢一定是图太大。这个站确实有 12 张未压缩的图片，但把它们优化完只省下 400 毫秒。真正的大头是另外三项：
- 中文字体文件：一个 4 MB 的字体包，阻塞了首屏文字渲染
- 第三方脚本：统计、客服、地图三个脚本串行加载，加起来 1.8 秒
- CSS 冗余：一个 UI 框架被整包引入，实际只用了不到 6%
我们按这个顺序处理
- 字体改为异步加载，同步回退到系统字体栈，中文字体改用子集化
- 第三方脚本全部加 defer，客服组件改成点击后再加载
- 移除未使用的 CSS，从 380 KB 降到 46 KB
- 图片转成 WebP 并加上宽高属性，避免布局抖动
- 开启服务端 gzip 与浏览器缓存
- 首屏关键 CSS 内联，其余样式延迟加载
哪些优化其实没用
顺便说几个我们试过但收益很小的做法，省得你浪费时间：
- 把所有 JS 合并成一个文件：在现代 HTTP/2 环境下收益接近零
- 开启全站 CDN：这个站 90% 流量来自同一个省，CDN 只快了 60 毫秒
- 把图片质量压到 40%：省了体积，但视觉上明显发糊，客户不接受
给出一个性能预算
优化做完不代表守住了。后来我们和客户约定了一个性能预算，写进运维清单，每次上新功能前对照检查：
- 首屏加载（4G 中端机）不超过 1.5 秒
- 首页总资源体积不超过 800 KB
- 第三方脚本数量不超过 3 个
- LCP 不超过 2.5 秒，CLS 不超过 0.1
预算的意义在于，它把“网站变慢了”这件模糊的事，变成了可以提前拦住的具体数字。
这篇就先写到这。有具体场景想讨论，直接打电话比留言快。