两百毫秒和等了三秒

一个客户坚持说站点要等三四秒才出内容，我跑拨测，第一次请求两百毫秒就完成了，两边数据对不上。他还发了录屏，确实是白屏了好几秒。

后来才想明白，我们说的「快」根本不是一件事。他描述的是「看到内容」，我测的是「服务器把 HTML 发完」。

拨测覆盖的是哪一段

从发起解析开始，到 TCP 连通、TLS 握手、服务器返回第一个字节，再把响应体收完。五段耗时加起来，就是这一次请求的完整生命周期。

它结束的时间点很明确：响应体接收完毕。页面之后发生什么，它不关心，也看不到。

网站测速：多站点分段耗时与状态码

网站测速：多站点分段耗时与状态码

它看不见的那一段

HTML 收到之后，浏览器要解析文档、构建 DOM、请求 CSS 和 JS、执行脚本、计算样式、布局、绘制。图片、字体、第三方统计脚本，会在这之后陆续加载。

如果脚本是阻塞渲染的，用户就得等它下载并执行完才能看到内容。这些时间，全在拨测的范围之外。

这也是为什么同一台机器加一个统计脚本，用户感受能差出一截，而服务器的各项指标毫无变化。

首屏为什么会被拉长

首屏慢，常见原因不在服务器。大图没压缩、字体文件加载慢、第三方脚本超时、请求串行排队，都会让页面「看起来慢」。

这些在拨测里可能表现为：TTFB 正常、下载段也不长，主页面请求很快完成。数据很好看，体验很差。

反过来，如果 TTFB 明显偏高，问题确实在后端，前端再怎么优化也救不回来。

找元凶的方法很土但有效：把页面资源按体积和耗时排一遍，通常最靠前的那两个就是答案。

怎么用拨测判断边界

用宝塔拨测的网站测速跑多地区多运营商节点，先确认服务端这一段稳不稳。

TTFB 短、下载正常、状态码正常，说明服务端交付没问题，用户的慢大概率在前端。这时候就别再去调服务器参数了，方向不对。

如果多个地区都慢，而且慢在同一段，那才是服务端或线路的问题，按分段继续查。

复测和浏览器侧验证

服务端确认没问题，就得换工具看首屏。浏览器开发者工具的网络面板能看到每个资源的耗时和顺序，性能面板能看渲染和脚本执行。

对比方法：拨测做基线，确认同一时段服务端正常；浏览器侧复现用户环境，找出是哪个资源拖住了首屏。

浏览器测试要保持环境一致，首次访问和二次访问差别很大，测首屏记得先清缓存。

两边都测，结论才完整。只拿一个数解释用户体验，很容易各说各话。