网站速度实测：同一个首页连测三次，中位数差了 542 毫秒

实测 · 2026-08-20 · 30 个网站 · 每站测三次

样本与口径：自 2026-08-15 起一直在用的那 30 个站。2026-08-20，每个首页连发三次请求，浏览器 UA，跟随重定向，出口在日本、经本机一跳代理。时间取 curl 自己的 write-out 值，每站报三次的中位数，三次原值全部保留。

网站速度这件事，量出来的数比想象中不牢靠。26 个可用首页的首字节耗时中位数是 1,118 毫秒，最快 554、最慢 2,723。但真正该记住的是另外两个数：中位数那个站的等待里，77% 发生在请求发出去之前；同一个站隔几秒再测一遍，结果平移了 542 毫秒。

怎么测的

规则跑数前写死，跑完一个字没改。

1. 对 https://<域名>/ 连发三次，跟随重定向，浏览器 UA，失败不重试。
2. 每一次都记下 time_namelookup、time_connect、time_appconnect、time_starttransfer、time_total。
3. 每站取三次的中位数，并把三次原值一起留着，让波动看得见。

两个站返回 403（stackoverflow.com、medium.com），两个返回 200 但给的是挑战页或空壳（www.canva.com、www.reddit.com）。这四个不进下面的中位数，可用样本 26。30 个站全部走 HTTP/2。

网站速度从快到慢，差了大约五倍

面板里没有一个是坏的，也没有一个按 Google 自己给的门槛算得上快。

26 个里 11 个在 1 秒以内，7 个超过 1.5 秒。总耗时中位数 2,048 毫秒，最长的是 www.nytimes.com 的 5,121 毫秒 —— 那 1,432,105 字节里，慢的不是等待，是下载。

参照系来自 web.dev 的 TTFB 文档，2026-08-20 访问：「Good TTFB values are 0.8 seconds or less, and poor values are greater than 1.8 seconds.」同一页还写了它「isn't a Core Web Vitals metric」，所以那是参考线，不是判决。

四分之三的等待，花在请求发出去之前

这一条会改变上面那张表的含义。把每站的中位首字节耗时拆成「建连接」和「建完之后」两段，建连接那段在中位数的站上占 77%，最低的一个也有 45%。

这里的「建连接」= DNS + TCP + TLS，也就是通往源站的那条隧道，在请求的第一个字节发出之前就已经谈完了。railway.com 那 1,599 毫秒里，留给服务器的只有 73 毫秒。把这个数叫作「服务器响应时间」，量级就错了。

这一条对做出海的人格外要紧：从国内或者从一台挂着代理的机器 ping 一下海外站，量到的大头是那条链路，不是对方的服务器。换个出口重测，排名就会变。

单次读数说明的是你在哪儿测，不是你测的那台服务器有多快。

同一个站隔几秒再测，差了 542 毫秒

每个站都连测了三次。一个站自己最快和最慢那两次之间的差，中位数是 542 毫秒 —— 大约是它自己中位首字节耗时的一半。

vercel 是最极端也最说明问题的一个。第一次 3,764 毫秒，第二次 488 毫秒，快了八倍，中间什么都没变，只是刚刚对这个主机开过一次连接。如果我们只测一次，vercel 会在一张表上垫底、在另一张表上靠前。

爬虫为什么在意这件事

Google 把服务器响应时间写进了「它愿意抓多少」的判据里，不只是用户体验的事。抓取预算文档原文，2026-08-20 访问于 developers.google.com：「If the site responds consistently and its response times (including latency and Time-to-First-Byte) remain stable or improve, the limit goes up, meaning more connections can be used to crawl.」

同一页也写了反面：变慢、返回 5xx、或者出现 HTTP 429 这类限流信号，上限就往下调。那句话里真正起作用的是两个词 —— consistently 和 stable。Google 描述的是它对一段时间里的模式做反应，而模式恰恰是单次读数看不出来的东西。

这次测量回答不了什么

它分不开你的服务器和我们的网络。上面每一个数里都含 DNS 解析、一跳代理、一次 TLS 握手，以及从大阪到源站的那条路径，单客户端没有办法把责任拆开。所以绝对值是这次测量的属性，不是那 26 个站的属性。

我们也没有从爬虫自己的网段测过、没换时段测过、没测过冷连接。三次连发共享第一次建立起来的热状态，这是 vercel 那八倍差最可能的解释 —— 但那是解释，不是我们验证过的结论。

怎么拿到一个能拿来做决定的数

三个习惯，外加一件该停掉的事。

• 拿自己和自己比，跨时间比；别拿自己和别人比一次。同一台机器、同一时段、同一条路径，重复测。
• 至少测三次取中位数，并且把极差一起记下来。这批数据里极差是中位数的一半，不带极差的读数不算测量。
• 下结论之前先把建连接和服务器耗时拆开。如果九成时间花在握手上，优化应用是白干。
• 别用自己电脑测出来的数当作服务器响应时间报上去。整篇实测要提防的就是这个数。

改动之前先把起点存下来，是同一条纪律用在搜索数据上的样子，做法在改之前先存基线。另外两件在爬虫拿到正文之前就耗掉的事：每一跳重定向，量在重定向要跳几次；本可以用 304 省掉的那次下载，量在Last-Modified 谁还在发。把这三件事放在整站尺度上盯住，是 QueryWin 正在做的事。

常见问题

你们是怎么测的？

2026-08-20，每个首页连发三次 curl 请求，浏览器 UA，跟随重定向，来自日本的单一客户端、经本机一跳代理。每站的数是三次的中位数，三次原值都在原始数据里。

首字节耗时多少算好？

Google 的 web.dev 文档（2026-08-20 访问）把 0.8 秒以内算好、1.8 秒以上算差，同时说明 TTFB 本身不是 Core Web Vitals 指标。这批面板的中位数 1,118 毫秒落在两者之间，但我们的链路在这个数里面，所以它不构成对那 26 个站的评判。

网站速度会影响收录吗？

Google 说响应时间（含 TTFB）会喂给抓取容量上限，并且点名它反应的是「稳定」。我们自己没有测过抓取速率与响应时间的关系，这里是在复述文档，不是在印证它。

为什么测三次而不是一次？

因为一次给的是错的。同一个站自己最快与最慢之间，中位数差 542 毫秒，最大的那个站差了 3,276 毫秒。