很多做蜘蛛池的人把精力放在入口页数量、IP 分布和链接结构上，却忽略了最基础的一环：页面多久能返回。蜘蛛的抓取队列是共享的，它给每个 URL 的等待时间是有限的。响应慢的页面，不是在“被耐心等待”，而是在被逐步降频，甚至直接从队列里丢掉。
先认清几个时间点
一次抓取请求，在蜘蛛这一侧大致会经历三个等待阶段：
- 连接阶段：从发起请求到 TCP/TLS 握手完成。这一步超时，通常是网络、防火墙或证书问题，页面再快也没用。
- 首字节阶段：也就是 TTFB。服务器收到请求到吐出第一个字节的时间，最能反映入口页的真实负担。
- 传输阶段：从首字节到页面下载完毕，主要受页面体积、分块传输和带宽影响。
三个阶段的容忍度并不一样。连接和首字节通常更严格，传输阶段相对宽松一些，但也不是无限。
为什么 TTFB 比总加载时间更值得盯
总加载时间可以靠加大带宽改善，TTFB 不行，它取决于程序处理、数据库查询、缓存命中和后端依赖。一个 TTFB 常年在一秒以上的入口页，即使页面只有 20KB，蜘蛛拿到的也是一次“昂贵”的抓取。长期下来，这类 URL 的抓取频次会明显低于同批次的快页面。
反过来说，一个页面总大小 300KB 但 TTFB 只有几十毫秒，往往比一个 20KB 却要等两秒的页面更受待见。
慢在哪里：按顺序排查
- 后端本身：动态生成的入口页如果每次都查库、拼模板，负载一上来就慢。
- 外部依赖：入口页里嵌了第三方统计、字体、图片外链，蜘蛛不会等这些，但服务器端渲染时如果同步拉取就会拖慢 TTFB。
- 重定向链：一次跳转就多一轮请求，多跳几次时间成倍增长，还增加了中途失败的风险。
- CDN 回源：节点没缓存，每次回源；源站又慢，蜘蛛看到的就是节点的慢。
- WAF 与限速：有些安全策略会对高频 IP 做延迟响应，表现为“时快时慢”。
- DNS 解析：解析慢或解析结果抖动，会在连接阶段就吃掉时间。
怎么量：别只看浏览器
浏览器有本地缓存和预连接，看到的数字偏乐观。更接近蜘蛛视角的做法是用命令行直接取首字节时间，例如用 curl 输出各项耗时字段，在没有 Cookie、没有浏览器缓存的前提下请求入口页，连续测几十次，看中位数和尾部延迟。重点不是平均值，而是最慢的那几次——蜘蛛撞上的往往就是最慢的那几次。
如果条件允许，从不同地区的机器各测一轮，避免把本地网络快误判成服务器快。
优化方向：从重到轻
- 入口页尽量静态化或强缓存，把动态拼装降到最低。
- 把非关键的外部资源从服务器端渲染路径里摘出去，改成前端异步加载。
- 合并跳转，入口页直接返回目标内容或只做一次跳转，不要串成长链。
- 给入口页单独开轻量服务，不要和后台业务抢同一个进程池。
- 检查 CDN 缓存规则，让入口页的命中率尽量高。
- 页面体积控制住，删掉用不到的脚本和大图。
超时与重试的取舍
蜘蛛侧的连接超时和读取超时是它自己定的，你改不了，能改的是让自己稳稳落在这个范围之内。经验上，把 TTFB 压在一个比较低的量级、总响应控制在可接受区间，是比较稳妥的做法。不要指望“偶尔慢一下没关系”，抓取是长期行为，频次是按历史表现累积起来的。
速度问题不会立刻让你掉收录，但它会悄悄改变蜘蛛来的频率。等你发现抓取变少时，往往已经慢了很久。
什么时候该怀疑不是速度问题
如果响应时间正常，但抓取依然上不来，就要往别处看：内容重复度、入口页互链是否形成孤岛、目标站承接是否合理、robots 是否挡掉了关键路径。速度只是入场券，不是全部。