测速报告里飘红最狠的那项通常不该第一个动

那个站是 2016 年上线的，无锡一家做精密零部件的外贸企业，栏目结构十年没动过。手机端连 4G 打开首页，从点击到首屏文字显形，掐表 5.2 秒。市场部拿着三份服务商的诊断报告过来，说测的是同一个站，可三家给出来的第一步动作完全不一样。

报告里的原始数据倒是对得上：等服务器返回第一个字节 1.4 秒，首屏图片 11 张合计 2.4 兆，阻塞渲染的脚本和样式请求 14 个，另有一个 480KB 的中文字体。分歧不在测量，在于这 5.2 秒该先算在谁头上。

第一条路：在源码之外加一层缓存和压缩

这条路的特点是一行 PHP 都不碰。在 Nginx 层打开 Brotli 压缩，等级给 4 到 5 就够，再往上 CPU 涨得比体积降得快，那份 90KB 的 HTML 压完剩 21KB 左右。静态资源统一挂一年期强缓存，文件名带上内容指纹，改了才换名。动态页做 5 到 10 分钟的整页缓存，前面再套一层 CDN。

无锡本地服务商这一档的报价通常在 3000 到 6000，工期两到三个工作日，其中一天半其实花在盘 URL 上，真正改配置只有几个小时。做完之后等待响应那一段一般能从 1.4 秒落到 0.25 秒上下。

它失效得也很干脆。第一种情况是老站的 URL 后面常年挂着推广参数，来源标记、会话 ID、活动编号各一套，每个参数组合都被当成一个新页面，缓存命中率可能只有三成。必须在缓存键里把无关参数剔掉，这一步漏了，前面的配置基本白改。第二种是带表单、验证码、登录态的页面被整页缓存会串号，上一个人填的手机号有概率出现在下一个人的页面上，这类路径要单独列白名单排除。第三种更隐蔽：日均访问两百、总页面数六十的站，很多页面在缓存过期之前压根没有第二次访问，整页缓存的命中率天然上不去，这种站只做压缩和强缓存就够了，整页缓存那部分钱可以省下来。

还有一笔不在报价单上的成本——谁来盘那份不能缓存的 URL 清单。网站建设合同里通常只写功能条目和页面数量，不会写这份清单归甲方还是乙方产出，等到上线出了串号才发现两边都以为对方会做。

第二条路：动模板里的资源，不动架构

那 14 个阻塞请求，拆开看有 8 到 10 个是历年沉积下来的：两套统计代码，其中一套是上一任服务商装的，账号早已联系不上；一个不再使用的社交分享插件；两套功能重叠的轮播库；一个在线客服脚本。逐个注释掉再回归一遍，是这条路里最耗人工的部分。当年网站建设时如果留下过一份第三方组件清单，这一步能省两三天，可多数十年老站没有这份东西。

图片是大头。11 张里有 7 张在首屏之外，补上延迟加载属性就不再参与首屏竞争；剩下 4 张转成 WebP，质量给 78 左右，2.4 兆能压到 400KB 上下，肉眼分辨不出差别。每张再补上宽高属性，避免图片到位时整页往下跳。字体那 480KB 要么做子集化，要么标题保留定制字、正文交回系统字体栈。

报价 6000 到 15000，周期 5 到 10 个工作日。它带来的秒数是三条路里最多的，首屏通常能从 5.2 秒降到 2.3 秒附近。

风险也集中在这里。老站源码经手过三家乙方，函数命名毫无规律，删掉一个看着没用的 jQuery 插件，可能顺手带崩留言表单的提交按钮，而这个故障要等到有客户投诉才会被发现。动手之前必须有一份连数据库一起的完整备份。另一个坑是图片路径写死在数据库富文本字段里，十年积累三千多条内容，批量换格式等于批量改字段，正则写错一个字符就是全站图裂。稳妥的做法是新旧格式并存，用 picture 标签给老浏览器留原图。如果客户群体偏政企采购，访问端还可能残留一定比例的旧内核浏览器，这个比例要从自己站的统计后台里查真实数字，不能套行业平均值。

第三条路：把底座换掉

PHP 从 5.6 或 7.0 升到 8.1，打开 OPcache，给列表页的筛选字段和排序字段建联合索引，主机从 2 核 4G 升到 4 核 8G，带宽从 3M 加到 10M。报价 8000 到 20000，主机年费从一千八涨到四千六，周期一到三周，其中大半时间在做回归测试。

收益上限很明确：它只在等待响应那 1.4 秒里活动。多数老站升到 PHP 8 并开启 OPcache 之后，这一段能降 0.6 到 1.0 秒，占 5.2 秒总时长不到两成，而它的报价是三条路里最高的。这笔钱放进十年前那次网站建设的总预算里，差不多占了三分之一。

它有两种典型的翻车方式。一是老代码里还留着已被移除的数据库函数或者早期的正则函数，PHP 8 一跑就整站白屏，升级前得先跑一遍兼容扫描，旧环境要保留到新环境稳定运行两周之后再关。二是那 1.4 秒未必是服务器慢——如果其中 1.1 秒卡在同步等一个外部接口，比如地图、天气或者第三方客服的初始化，那么换机器、升版本、加带宽全都没有反应，得先把那个请求改成异步或者加一层本地缓存。这件事必须实测，不能靠猜。至于带宽，它只在下载大图的时候才是瓶颈，图片还没压就先加带宽，等于花钱给浪费提速。

把三条路放回同一条 5.2 秒的时间轴

三份报告谁也说服不了谁，是因为大家都在讲自己那一段的好处。把 5.2 秒按阶段拆开就清楚了：等服务器返回第一个字节 1.4 秒，资源下载 2.6 秒，脚本和样式阻塞渲染 1.2 秒。

缓存压缩层动的是第一段的大部分，外加第二段里静态资源那一块，实际能带走 1.1 到 1.4 秒。前端瘦身动的是第二段和第三段，能带走 2.4 到 2.9 秒，是唯一有可能一次拿走一半以上时长的。底座升级全程只在第一段里活动，上限 0.8 到 1.0 秒。

三条路吃的段位几乎不重叠，这个结论有两层用处。往好处说，先做哪一条都不会让另外两条的收益缩水，不存在做早了浪费；往坏处说，没有任何一条能单独把 5.2 秒拉进 2 秒以内。谁承诺做完某一项就能进 2 秒，让他先把这三段的实测值分开量给你看，量不出来的方案不必再谈价格。

排序的第二个依据是出事之后能不能撤

缓存压缩层改的是服务器配置，出问题把那几行注释掉重载一次，五分钟回到原状。前端瘦身改的是模板文件和数据库里的内容，有完整备份的话回滚要半天，没备份就是不可逆的。底座升级最难撤，PHP 版本能切回去，索引能删掉，可只要中间产生过新的数据写入，就回不到那个干净的起点了。

所以同样收益的两件事，先做能撤的那件。这条规矩在网站建设的验收节点上几乎没人提，但它决定了改造期间这个站会不会有一天彻底打不开——对一个还在承接询盘的外贸官网来说，打不开半天的损失，比慢两秒一整年还大。

改完之后怎么确认是这一刀起的作用

一次只上一条路的改动，中间隔三天。三条一起上，出了问题不知道该回滚哪一条，最后往往全部退回原样。

测量条件要钉死：同一款手机、同一个时段、同样限速到 3Mbps、清掉缓存做首次访问，连续测五次取中位数。单次测速的波动能到 1.5 秒，拿单次结果去汇报是在赌运气。

更要紧的是别只盯着合成测速的分数。真正该看的是连续七天的真实访问数据：三秒内可交互的访问占比、跳出率、表单提交数。分数涨了而这三个数不动，说明动的地方不在访客真正卡住的位置。无锡这类以外贸和制造为主的企业站还得把海外访问和国内访问分开统计，海外那部分的瓶颈常常在链路上，本地怎么优化都看不到变化。

先动哪一处，看你的站在这四个问题上的答案

第一个问题：打开开发者工具的网络面板，看第一个 HTML 请求的等待时间。超过 800 毫秒，并且全站每天更新的内容不到三条，那就先做缓存压缩层，两三天见效，花钱最少，撤起来也最快。

第二个问题：首屏图片总量是否超过 1.5 兆，阻塞渲染的请求是否超过 10 个。只要中了任意一条，前端瘦身就该排到最前面，因为它能吃掉的秒数比另外两条加起来还多，先做别的等于让访客继续等那 2.6 秒。

第三个问题：后台保存一篇文章要不要等四秒以上，PHP 版本是不是还停在 5.x。两个都中，底座就绕不过去了，但兼容扫描没跑完、旧环境没留出来之前，不要动手。

第四个问题：三项全中怎么办。按能不能撤排：缓存压缩、前端瘦身、底座升级，每一步之间留一周观察真实数据。同时把这三段的实测秒数写进下一次网站建设的需求文档里，附上今天量到的值，下一任服务商就没法只挑对自己有利的那一段说话。

还有一个不花钱的动作现在就能做：把手机流量限速到 3Mbps，走到车间或者仓库这种信号一般的地方，打开自己公司的首页，掐表。这个数字比任何一份诊断报告都更接近客户看到的样子。