一条请求变慢，时间花在了哪里

先分阶段，再谈快慢

打开一个地址之前，会先经历域名解析、建立连接以及可能发生的 TLS 握手，服务器开始返回内容以后，才进入接收响应的阶段。整体耗时很有用，但它并不能单独说明是哪一步变慢。

记录时可以保留几个阶段的时间。curl 的这些计时通常从请求开始累计，因此不能把几个数值直接相加；两个相邻指标之间的差值，才更接近那一段所经历的时间。

给每次请求留一行结果

下面的例子展示域名解析、连接、TLS 握手、首字节和总时间。示例只输出计时，不保存页面正文；实际比较时仍要另外核对 HTTP 状态、接收字节数和请求是否完整完成。

curl -sS -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first=%{time_starttransfer} total=%{time_total}\n' https://example.com/

给数字保留上下文

相同地址在不同网络、不同出口或不同时间的表现可能不同。比较时尽量保持请求内容和工具设置一致，交替执行几个样本，同时记录实际连接的地址。一次快的结果，不能替代另一份真实失败的样本。

如果只完成了部分下载，就把它记为部分下载。首字节快，也不代表整个文件传输快。把阶段计时、完成状态和测试条件放在一起，才容易判断下一步应该检查什么。

参考：curl 官方手册：--write-out