蜘蛛不会等太久：TTFB 为什么值得管
蜘蛛访问入口页时，先建立连接、发请求，然后等待服务器返回第一个字节。这段时间就是 TTFB（Time To First Byte）。它不决定页面最终排名，但会影响蜘蛛在有限抓取预算里能访问多少 URL。如果每个入口页都要等两三秒，蜘蛛在同一时间段内能走完的路径就少了，抓取覆盖率自然受影响。这不是玄学，是资源分配的现实。
TTFB 里包含了哪些等待
- DNS 解析：把入口域名换成 IP 地址
- TCP 握手：建立连接
- TLS 握手：HTTPS 场景下协商加密
- 服务器端处理：程序执行、查库、模板渲染
- 回源：使用 CDN 时，缓存未命中会回源站取内容
- 网络传输：首字节从服务器到蜘蛛
大多数时候，慢在服务器端处理。入口页可能是动态生成的，还带了统计、外链检测、随机推荐之类的逻辑，这些都会在返回首字节之前发生。
入口页常见的“拖时间”写法
- 每次请求都查数据库，尤其是没有索引的模糊查询
- 页面里同步调用第三方接口，比如统计、IP 归属地、内容推荐
- 大量小文件、外链 JS/CSS 在响应前被阻塞
- 没有页面缓存，每次重新生成
- 日志写在同一块慢盘上，或长期开着实时调试
- CDN 回源没配缓存，每次都穿透到源站
可以落地的优化思路
下面这些做法不一定都要做，按自己的资源情况挑几项先试。
- 入口页尽量静态化或半静态化。内容变化不频繁的页面，生成 HTML 后直接返回，可以省掉大量计算。
- 加一层本地缓存。文件缓存、Redis、OPcache 都行，关键是命中率。命中率低，加缓存只是多绕一圈。
- 把第三方请求改成异步或延后。蜘蛛拿到的首字节不应该等外部服务。
- 用 CDN 缓存入口页。设置合理的缓存时间，并确认回源频率不会把源站打满。
- 日志和监控异步写。不要为了记录抓取而拖慢抓取本身。
- 检查数据库慢查询。给入口页查询加索引，避免每次扫全表。
别把“慢”误当成“稳”
有人觉得慢慢返回蜘蛛会更有耐心，其实相反。持续的高延迟可能会让蜘蛛降低对站点的抓取频率。还有一种情况是服务器压力大时返回 503 并带 Retry-After，这比超时更友好，但也不能成为常态。
状态码和超时怎么配合
正常返回 200，配合合理的缓存头。如果服务器确实忙不过来，返回 503 加 Retry-After，比让连接一直挂着要好。不要用 200 返回一个“正在加载”的空壳，蜘蛛不会等你加载完。
响应时间不是越短越好，但稳定比偶尔快更重要。蜘蛛更愿意访问一个持续在可接受范围内的站点。
怎么观察和验证
- 看服务器访问日志里的响应时间字段，按入口页分组统计
- 用 curl 或类似工具模拟蜘蛛请求，关注 time_starttransfer
- 检查监控里 TTFB 的 P95、P99，不只看平均值
- 对比优化前后，蜘蛛抓取频次和覆盖 URL 数的变化，注意这只是一个观察角度
几个容易忽略的细节
- HTTPS 握手也会计入首字节前的等待，HTTP/2 和会话复用能减少一些开销
- 入口页和静态资源分开域名或分开服务器，避免互相抢带宽
- 如果入口页需要跳转，跳转链路上的每一跳都会累加等待时间
- 深夜批量更新入口页时，注意别让生成任务和蜘蛛抓取撞在一起
什么时候不用太纠结 TTFB
如果入口页数量很少、抓取压力不大，或者瓶颈明显在别的环节，比如入口页质量、链接结构、域名历史，那么优先处理那些问题更实际。TTFB 只是其中一块拼图，不必把它当成唯一指标。
总结
TTFB 不是蜘蛛池的核心配置，却常常是抓取效率的隐形瓶颈。把入口页的响应时间控制在合理范围，配合缓存、静态化和稳定的状态码，比反复调整蜘蛛池结构更实在。先量再调，别凭感觉。