蜘蛛不會等太久：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 不是蜘蛛池的核心配置，却常常是抓取效率的隐形瓶颈。把入口頁的响應時間控制在合理范围，配合缓存、静態化和稳定的狀態碼，比反复調整蜘蛛池结构更實在。先量再調，別凭感觉。