很多做蜘蛛池的人把精力放在入口頁數量、IP 分布和連結结构上，却忽略了最基础的一环：頁面多久能返回。蜘蛛的抓取队列是共享的，它给每個 URL 的等待時間是有限的。响應慢的頁面，不是在“被耐心等待”，而是在被逐步降频，甚至直接從队列里丢掉。
先認清几個時間点
一次抓取請求，在蜘蛛這一侧大致會经歷三個等待阶段：
- 连接阶段：從發起請求到 TCP/TLS 握手完成。這一步超时，通常是網絡、防火墙或證书問题，頁面再快也没用。
- 首字节阶段：也就是 TTFB。服務器收到請求到吐出第一個字节的時間，最能反映入口頁的真實负担。
- 传輸阶段：從首字节到頁面下载完毕，主要受頁面体积、分块传輸和带宽影响。
三個阶段的容忍度並不一样。连接和首字节通常更嚴格，传輸阶段相對宽松一些，但也不是無限。
為什么 TTFB 比總加载時間更值得盯
總加载時間可以靠加大带宽改善，TTFB 不行，它取决于程序處理、資料库查询、缓存命中和後端依赖。一個 TTFB 常年在一秒以上的入口頁，即使頁面只有 20KB，蜘蛛拿到的也是一次“昂贵”的抓取。長期下来，這類 URL 的抓取频次會明顯低于同批次的快頁面。
反過来说，一個頁面總大小 300KB 但 TTFB 只有几十毫秒，往往比一個 20KB 却要等两秒的頁面更受待见。
慢在哪里：按顺序排查
- 後端本身：動態生成的入口頁如果每次都查库、拼模板，负载一上来就慢。
- 外部依赖：入口頁里嵌了第三方統計、字体、图片外鏈，蜘蛛不會等這些，但服務器端渲染时如果同步拉取就會拖慢 TTFB。
- 重定向鏈：一次跳轉就多一轮請求，多跳几次時間成倍增長，還增加了中途失敗的風險。
- CDN 回源：节点没缓存，每次回源；源站又慢，蜘蛛看到的就是节点的慢。
- WAF 與限速：有些安全策略會對高频 IP 做延迟响應，表現為“时快时慢”。
- DNS 解析：解析慢或解析结果抖動，會在连接阶段就吃掉時間。
怎么量：別只看浏览器
浏览器有本地缓存和预连接，看到的數字偏乐观。更接近蜘蛛视角的做法是用命令行直接取首字节時間，例如用 curl 輸出各項耗时字段，在没有 Cookie、没有浏览器缓存的前提下請求入口頁，连續测几十次，看中位數和尾部延迟。重点不是平均值，而是最慢的那几次——蜘蛛撞上的往往就是最慢的那几次。
如果條件允许，從不同地区的机器各测一轮，避免把本地網絡快誤判成服務器快。
優化方向：從重到轻
- 入口頁尽量静態化或强缓存，把動態拼装降到最低。
- 把非關键的外部资源從服務器端渲染路径里摘出去，改成前端异步加载。
- 合並跳轉，入口頁直接返回目标内容或只做一次跳轉，不要串成長鏈。
- 给入口頁單獨開轻量服務，不要和後台业務抢同一個進程池。
- 检查 CDN 缓存規則，让入口頁的命中率尽量高。
- 頁面体积控制住，删掉用不到的脚本和大图。
超时與重试的取舍
蜘蛛侧的连接超时和讀取超时是它自己定的，你改不了，能改的是让自己稳稳落在這個范围之内。经驗上，把 TTFB 压在一個比較低的量級、總响應控制在可接受区間，是比較稳妥的做法。不要指望“偶尔慢一下没關系”，抓取是長期行為，频次是按歷史表現累积起来的。
速度問题不會立刻让你掉收錄，但它會悄悄改變蜘蛛来的频率。等你發現抓取變少时，往往已经慢了很久。
什么时候该怀疑不是速度問题
如果响應時間正常，但抓取依然上不来，就要往別處看：内容重复度、入口頁互鏈是否形成孤岛、目标站承接是否合理、robots 是否挡掉了關键路径。速度只是入场券，不是全部。