接口很快，首屏还是慢

一个后台系统，接口普遍几十毫秒，用户却说打开首页要等两三秒。我先去看服务器，CPU、内存、数据库都正常。

后来用浏览器打开网络面板，才发现首页要加载几十个资源，其中两个脚本还是阻塞渲染的。那次之后我先看资源数，再看服务器。

五段测的是一个请求

测速工具测的是某一次请求：DNS、TCP、TLS、TTFB、下载。

首页 HTML 很快，只说明文档本身快。它引用的 CSS、JS、字体、图片，是另外的请求，各自有各自的耗时。一次请求的耗时再漂亮，也不代表整页的耗时可接受。

所以「接口快」和「首屏慢」完全可以同时成立。

单独测资源

把首页里最大的几个资源地址拿出来，逐个用宝塔拨测的网站测速测。

如果某个 JS 文件下载段特别长，那就是体积或者带宽的问题。

如果静态资源 TTFB 很高，可能是 CDN 没命中、回源慢，或者走了动态处理。

字体文件也常被忽略，一个没压缩的中文字体能有好几兆。把资源列表按体积排个序，前十名通常就能解释大半问题。

关键渲染路径

浏览器拿到 HTML 后，遇到阻塞脚本会停下来等它下载并执行。

CSS 也会阻塞渲染。第三方统计、客服脚本、字体服务，任何一个慢，首屏都会被拖住。

如果这些资源来自不同域名，每个域名还要重新解析、连接、握手，成本会叠加。预加载和 defer 能缓解，但前提是资源本身别太大。

三条线分开测

我通常会测三个地址：首页 HTML、一个关键接口、一个最大的静态资源。

首页快、接口快、资源慢，问题在前端资源和分发。

首页慢、接口快，问题在模板渲染，或者首屏依赖的接口串行。

三个都慢，才轮到查服务器和带宽。三条线分开测，比笼统测首页有用得多。首屏时间和接口耗时不是一个指标，别拿一个证明另一个。用户看到的是白屏，不是你的 TTFB。

复测和验证

改完压缩、拆包、加预加载之后，用同一批节点复测同一批资源，看下载段有没有下降。

浏览器侧再看一眼首屏时间，确认用户感知真的变好了。

服务端指标好看，不等于用户打开得快。这两件事得分开验证。

优化资源顺序，有时比换服务器有用。第三方脚本经常超时，考虑异步加载或者去掉，别让一个统计脚本拖垮整页。给前端定一个性能预算，超了就查，比临时优化靠谱。记录里写清资源 URL 和体积，下次对比才有依据。