做蜘蛛池的人常常把精力放在域名数量、内容模板和链接结构上，却容易忽略一件更基础的事：入口页的响应速度。爬虫的抓取时间是有限的，它在同一个站点上停留的每一秒都要花在排队上。如果入口页每次都慢半拍，抓取预算就会被消耗在等待上，而不是消耗在发现新 URL 上。
TTFB 慢，慢在哪一段
很多人笼统地说“服务器慢”，其实从爬虫发出请求到拿到完整页面，中间有几段可以分别出问题：
- DNS 解析：域名解析服务不稳定，每次都要重新查一遍。
- TCP 与 TLS 握手：证书链太长、协议版本老旧，握手要多走几个来回。
- 首字节时间（TTFB）：服务端处理时间，通常是数据库查询、后端逻辑、反向代理回源叠加的结果。
- 内容传输：页面体积过大、首屏依赖大量外部资源，下载阶段被拖长。
爬虫侧看到的只是总耗时，但对运维侧来说，这四段是四种不同的修法。先定位再动手，比盲目加机器更有效。
慢下来之后，爬虫会怎么反应
不同搜索引擎的超时容忍度不一样，但总体逻辑相似：
- 单次请求超时后，爬虫通常会在短暂间隔后重试一两次。
- 如果同一主机连续超时，抓取频率会被下调，站点被抓的间隔被拉长。
- 持续如此，该主机在调度里的优先级下降，连带的受信任程度也会受影响。
- 极端情况下，入口页长时间不可用，之前已经建立的“这里值得来”的印象会慢慢衰减。
这里要注意一个常见误解：超时不是“没抓到”，而是“抓了但白抓”。它同样消耗了调度名额，只是没有换来任何 URL 发现。
爬虫的耐心比人短得多。人愿意为一个页面等三秒，爬虫在一次抓取里可能只给几百毫秒到几秒的窗口。
并发上来了，速度反而更慢
蜘蛛池的入口页数量往往是几百上千个，如果它们分布在同一批服务器、同一批 IP 上，爬虫集中访问时就会形成短时间的高并发。这时候常见的现象是：单个页面空跑很快，但一被批量抓取就集体变慢。
原因通常不在代码，而在几个共享资源上：
- 反向代理的连接数上限。
- 数据库连接池被占满。
- 同一台机器上其他入口页在抢 CPU。
- 日志同步写入磁盘造成的 IO 抖动。
把入口页做成静态文件、减少每次请求都要查库的操作，通常比升级配置更立竿见影。
可以落地的几个动作
- 给静态页开缓存：入口页内容不常变，直接走 CDN 或本地缓存，把 TTFB 压到几百毫秒以内。
- 关闭不必要的阻塞资源：入口页不需要的统计脚本、字体、大图，能删就删。
- 控制页面体积：HTML 本身尽量精简，把长内容拆到下一层页面。
- 做好超时兜底：后端接口设置合理超时，宁可返回简化版页面，也不要让请求挂死。
- 分散负载：入口页不要全挤在一两台机器上，按域名或按批次分开部署。
- 定期抽样测速：用第三方测速工具从多个节点测入口页，别只在自己网络里看。
两个容易踩的坑
只看平均值不看长尾
平均 TTFB 300 毫秒听起来没问题，但如果有 10% 的请求要 5 秒以上，爬虫遇到的就是那 10%。关注 P95、P99，比关注平均值更贴近爬虫的真实体验。
为了提速把内容砍空
有人发现页面越轻爬得越快，于是把入口页做成几乎空白。速度是上去了，但页面没有可抓的内容，爬虫同样不会顺着往下走。速度和内容体量需要一起看，不能单方面压。
小结
响应速度不是蜘蛛池里最显眼的变量，却是最容易拖后腿的那一个。把 TTFB、页面体积和并发承载能力这三件事理顺，抓取预算才更有可能花在真正有价值的跳转上。它不保证收录，也不会直接带来排名，但能让前面做的内容与链接工作不至于白白浪费在等待里。