这三个方法不是「快慢之分」，是「测的东西不一样」。搞清楚差别，比记住哪个数字好看重要。

HEAD：只交换信封

服务端返回头，不返回正文。响应里状态码、Content-Length、Cache-Control 都在，唯独没有内容。

对拨测来说，DNS、TCP、TLS、TTFB 这四段是完整的，下载段几乎是空的。因为真的没东西可下载。

所以拿 HEAD 的结果说「页面加载很快」，逻辑上是不成立的。你测的是「服务端愿不愿意理我」，不是「用户等了多久」。

GET：完整走一遍

GET 把正文一起返回。下载段从零变成真实值，取决于 HTML 大小、压缩有没有开、带宽够不够。

这是最接近浏览器首次请求的方式。用户打开页面时发的就是 GET，你测的也是 GET，结论才可以直接往用户身上套。

差别有多大？一个开了 gzip 的 50KB 页面和一个没开压缩的 500KB 页面，在下载段上就是数量级的差距。HEAD 完全看不出这个区别。

POST：方法层面的探测

高级选项里的 POST 不带请求体，所以它测的不是业务处理时间，而是「这个方法能不能用」。

它的价值在于快速区分失败原因。405 是方法没开，403 是策略拦截，超时是链路或服务不可用。三个错误码对应三条排查路径，比笼统地说「接口有问题」有用得多。拿不准的时候，用 IP 查询 看一下解析结果，先确认你测的是哪一台。

所以该怎么读结果

看连通性和应用响应，用 HEAD，干扰最小。

看用户实际体验，用 GET，这是唯一能反映下载成本的。

看接口的方法和拦截，用 POST，别指望它给出业务耗时。

一个实用习惯

遇到「用户说慢、你测正常」的分歧，先换 GET 重测。大部分分歧到这一步就消失了——因为问题在体积，而 HEAD 看不见体积。

如果换了 GET 还是快，再往下查前端资源和渲染。这条分界线在 网站测速 的高级选项里，点一下就能切。