本文目录
2025 年 1 月，我们做了一次全站测速。用一个中端安卓机、4G 网络，打开首页，LCP 4.8 秒。这个数字让我在办公室坐了一会儿——我们天天跟客户讲性能重要，自己的站是 4.8 秒。
更尴尬的是，测的这天服务器状态正常，没有突发流量，也没有人同时在跑备份。4.8 秒就是日常水平。
先看资源，不看代码
拆开看首屏加载了什么：一个 1.2MB 的轮播图、三个图标字体文件、两个 Google Fonts 字重、一个统计脚本、一个客服插件、一个不知道什么时候加的动画库。首屏请求 34 个，总传输 3.4MB。
问题很清楚，不是代码写得差，是资源堆得太多。我们定了六项整改，按投入产出排序。
六项动作
一，全站 HTTPS。这件事早就该做，一直拖着是因为有几百个站要换证书。用自动化脚本批量签发和部署，两周完成。
二，开 HTTP/2。多路复用之后，34 个请求的排队问题缓解了一大半。这一项改动最小，收益最直接。
三，图片全部转 WebP，首屏轮播图从 1.2MB 压到 180KB，并加了 width/height 防止布局抖动。
四，关键 CSS 内联，其余样式异步加载。首屏渲染不再等完整样式表。
五，字体本地化。去掉 Google Fonts，中文字体只保留一个子集，用 font-display: swap。
六，砍掉两个不用的脚本：那个动画库没人记得为什么加，客服插件换成了点击后再加载。
结果与一个新习惯
三个月后重测：LCP 从 4.8 秒降到 1.9 秒，首屏请求从 34 个降到 11 个，传输从 3.4MB 降到 620KB。移动端跳出率下降 12%，平均停留时间涨了 40 秒。
比数字更重要的是，我们第一次给全站定了性能基线：移动端 4G 环境下，LCP 不超过 2.5 秒、CLS 小于 0.1、首屏请求不超过 15 个。每次上线前跑一次，超了就退回改。
基线这个事听起来很基础，但它是分水岭。没有基线，优化就是一次性运动，改完几个月又慢慢堆回去；有了基线，性能变成了持续的约束。
客户站点同步执行
2025 年下半年，这套标准推到了客户站点。新项目上线必须过基线，老项目按季度体检。半年内，客户站点的平均 LCP 从 3.6 秒降到 2.2 秒。
有一个客户一开始不理解，说"我们行业网站上得慢一点没关系"。我们把他们的移动端数据拉出来：跳出率 74%，平均停留 26 秒。改完之后跳出率 58%，停留 51 秒。数据比说服有用。
还在做的事
下一步是把图片处理和字体子集化写进系统，让优化变成默认行为，而不是每次靠人记得。这件事在 2026 年开始做，目标是新站上线就达标，不需要额外整改。
性能优化不难，难的是不复胖。定一条基线，比做十次专项整改都管用。
