做蜘蛛池的人常常把精力放在域名數量、内容模板和連結结构上，却容易忽略一件更基础的事：入口頁的响應速度。爬虫的抓取時間是有限的，它在同一個站点上停留的每一秒都要花在排队上。如果入口頁每次都慢半拍，抓取预算就會被消耗在等待上，而不是消耗在發現新 URL 上。
TTFB 慢，慢在哪一段
很多人笼统地说“服務器慢”，其實從爬虫發出請求到拿到完整頁面，中間有几段可以分別出問题：
- DNS 解析：域名解析服務不稳定，每次都要重新查一遍。
- TCP 與 TLS 握手：證书鏈太長、协议版本老舊，握手要多走几個来回。
- 首字节時間（TTFB）：服務端處理時間，通常是資料库查询、後端逻辑、反向代理回源叠加的结果。
- 内容传輸：頁面体积過大、首屏依赖大量外部资源，下载阶段被拖長。
爬虫侧看到的只是總耗时，但對运维侧来说，這四段是四種不同的修法。先定位再動手，比盲目加机器更有效。
慢下来之後，爬虫會怎么反應
不同搜尋引擎的超时容忍度不一样，但總体逻辑相似：
- 單次請求超时後，爬虫通常會在短暂間隔後重试一两次。
- 如果同一主机连續超时，抓取频率會被下調，站点被抓的間隔被拉長。
- 持續如此，该主机在調度里的優先級下降，连带的受信任程度也會受影响。
- 极端情况下，入口頁長時間不可用，之前已经建立的“這里值得来”的印象會慢慢衰减。
這里要注意一個常见誤解：超时不是“没抓到”，而是“抓了但白抓”。它同样消耗了調度名額，只是没有換来任何 URL 發現。
爬虫的耐心比人短得多。人愿意為一個頁面等三秒，爬虫在一次抓取里可能只给几百毫秒到几秒的窗口。
並發上来了，速度反而更慢
蜘蛛池的入口頁數量往往是几百上千個，如果它們分布在同一批服務器、同一批 IP 上，爬虫集中訪問时就會形成短時間的高並發。這时候常见的現象是：單個頁面空跑很快，但一被批量抓取就集体變慢。
原因通常不在代碼，而在几個共享资源上：
- 反向代理的连接數上限。
- 資料库连接池被占满。
- 同一台机器上其他入口頁在抢 CPU。
- 日誌同步寫入磁盘造成的 IO 抖動。
把入口頁做成静態文件、减少每次請求都要查库的操作，通常比升級配置更立竿见影。
可以落地的几個動作
- 给静態頁開缓存：入口頁内容不常變，直接走 CDN 或本地缓存，把 TTFB 压到几百毫秒以内。
- 關閉不必要的阻塞资源：入口頁不需要的統計脚本、字体、大图，能删就删。
- 控制頁面体积：HTML 本身尽量精简，把長内容拆到下一层頁面。
- 做好超时兜底：後端接口設定合理超时，宁可返回简化版頁面，也不要让請求挂死。
- 分散负载：入口頁不要全挤在一两台机器上，按域名或按批次分開部署。
- 定期抽样测速：用第三方测速工具從多個节点测入口頁，別只在自己網絡里看。
两個容易踩的坑
只看平均值不看長尾
平均 TTFB 300 毫秒听起来没問题，但如果有 10% 的請求要 5 秒以上，爬虫遇到的就是那 10%。關注 P95、P99，比關注平均值更贴近爬虫的真實体驗。
為了提速把内容砍空
有人發現頁面越轻爬得越快，于是把入口頁做成几乎空白。速度是上去了，但頁面没有可抓的内容，爬虫同样不會顺着往下走。速度和内容体量需要一起看，不能單方面压。
小结
响應速度不是蜘蛛池里最顯眼的變量，却是最容易拖後腿的那一個。把 TTFB、頁面体积和並發承载能力這三件事理顺，抓取预算才更有可能花在真正有價值的跳轉上。它不保證收錄，也不會直接带来排名，但能让前面做的内容與連結工作不至于白白浪費在等待里。