网站打开慢测试：定位 DNS、连接和服务器等待
打开网页前半段很慢时，用 curl 分别记录解析、连接、TLS、首字节和传输时间，结合跳转与服务端日志缩小故障范围。
网站打开慢测试，可以先把导航前半段拆开：域名解析、连接、TLS、首字节和正文下载。这样能判断等待更接近网络建立，还是请求已经发出后迟迟没有响应。命令行计时适合找线索，但不会告诉你全部浏览器体验。
先做一次有边界的 HTTPS 请求
以下 Windows 示例只请求一个 URL，不自动跟随跳转。将域名替换为自己有权检测的网站，少量运行即可：
curl.exe -sS -o NUL --connect-timeout 10 --max-time 30 -w "code=%{http_code} ip=%{remote_ip} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} pre=%{time_pretransfer} first=%{time_starttransfer} total=%{time_total}\n" https://example.com/时限是示例命令的设置，不是网站性能标准。默认情况下，curl 收到 HTTP 错误响应也未必返回非零进程状态，因此要同时看状态码、标准错误和退出状态。没有取得有效响应时，000不是网站返回的 HTTP 状态码。字段定义见 curl 官方手册。
这些数字大多是累计时间，不能直接相加
在没有跳转、没有连接复用等干扰的简单 HTTPS 请求中，可以用相邻时间点的差值帮助理解阶段：
| 观察对象 | 参考差值 |
|---|---|
| 解析结束 | time_namelookup |
| 解析后到 TCP 建立 | time_connect − time_namelookup |
| TCP 后的 TLS 握手 | time_appconnect − time_connect |
| 准备传输后到首字节 | time_starttransfer − time_pretransfer |
| 首字节后到请求完成 | time_total − time_starttransfer |
代理、不同协议和连接复用可能改变解释，不能无条件套用。首字节前的等待还包含请求发送与网络往返，不等于纯后端计算时间。浏览器导航 TTFB 的边界也要按其定义看，可参照 TTFB 官方说明。
沿最长的阶段继续补证据
解析慢，核对解析器、A/AAAA 答案与本地网络；连接慢，检查目标地址、端口和同地区路径；TLS 慢或失败，查看证书、主机名与握手错误；首字节等待长，结合 CDN、代理和应用日志；正文下载慢，则检查大小、压缩与传输。
这些是排查方向，不是仅凭一个差值就确定根因。如果原地址返回跳转，要记录整条链，必要时逐跳检查；不要把跳转前的短请求当作最终页面全部耗时。
文档返回后仍慢，就转到浏览器
curl 不运行页面脚本，也不下载整套图片与样式。文档很快、首屏却慢时，继续看浏览器瀑布图和主线程。复测保持网址、网络、时间和页面版本一致，并保留失败，不只记录成功时的数字。
后半段可以按HTML 返回后首屏仍慢的排查方法处理；各类延迟的边界则见RTT、建连与首字节区别。