响應時間是抓取鏈路里最先被感知的信号
蜘蛛要拿到一個入口頁，第一步不是解析 HTML，而是建立连接、發出請求、等服務器返回第一字节，這個等待過程就是 TTFB。它慢的时候，蜘蛛不會给你报错，但行為會變：抓取間隔拉長、並發降低、同一批 URL 抓完的周期變長。
很多人看到日誌里蜘蛛訪問稀疏，第一反應是池子不够、域名太少。在換资源之前，先把入口頁的响應時間確認一遍，往往成本更低。
先分清“抓取慢”到底慢在哪
抓取鏈路上常见的延迟点有几個：DNS 解析、TCP 與 TLS 握手、服務器排队、後端程序渲染、以及 CDN 回源。任何一环卡住，蜘蛛看到的都是同一個结论——這個站有点慢。
- DNS 解析：解析耗时過長或權威服務器不稳定，每次连接都要多等一截。
- TCP/TLS 握手：證书鏈不完整、未開啟會话复用，握手次數會明顯增加。
- 服務器排队：並發连接被占满时，新請求只能等前面的處理完。
- 後端渲染：動態生成入口頁、查库、調用外部接口，都會推高首字节時間。
- 回源與中間层：CDN 未命中时回源，源站慢會直接体現在首字节上。
慢到什么程度蜘蛛會調整策略
抓取端一般有自己的超时阈值，常见做法是连接超时和讀取超时分開設定。当响應長期偏慢，抓取端不會立刻把入口頁彻底放弃，而是倾向于降低對本站的請求频率，把预算挪给响應更快的站点。對入口頁来说，這意味着同一個入口被回訪的間隔變長，新 URL 被發現的节奏也跟着慢下来。
三個最容易被忽略的延迟来源
1. 入口頁的模板渲染
入口頁如果每次請求都要走一遍模板引擎、查询連結列表、做随机排序，單次几十毫秒的差异在低並發时不明顯，一旦抓取量上来就會被放大。静態化或加一层短时缓存，通常比直接升級服務器更有效。
2. CDN 的命中率
命中率低时，每個請求都回源，源站的压力和响應時間同时上升。可以检查缓存規則是否把带參數的入口 URL 排除了，或者缓存時間設定得過短。
3. 第三方资源與統計脚本
入口頁里嵌入的外部 JS、統計代碼、字体文件，如果抓取端不执行 JS，影响有限；但如果這些资源阻塞了服務端渲染或造成額外等待，同样會拖慢首字节。能用静態文字表達的内容，尽量不要依赖外部調用。
自查與優化顺序
- 從外部網絡用 curl 抓取入口頁，分別记錄 DNS、连接、首字节、總耗时四項資料。
- 连續抓取多次，看波動情况。偶發慢和持續慢，處理方式並不相同。
- 關掉 CDN 直连源站做對比，確認延迟出在源站還是中間层。
- 检查入口頁是否每次請求都動態生成，能否加缓存或做静態化。
- 確認蜘蛛 UA 的請求走的是同一套鏈路，没有被特殊規則绕到更慢的路径上。
观察哪些指标更靠谱
單看蜘蛛總訪問量意义不大，建议结合日誌里的响應時間分布、同一入口的回訪間隔、以及單次會话抓取的 URL 數量一起看。如果响應時間中位數在下降，回訪間隔却在拉長，那問题可能不在速度，而在内容更新或連結结构上，需要分開排查。
响應時間不是孤立指标。它和抓取预算、回訪频率、URL 發現速度互相牵连，改一處最好观察一段時間再動下一處。
常见誤区
- 把“蜘蛛不来”直接归因于资源不够，忽略入口頁本身的速度問题。
- 認為蜘蛛没有超时提示就等于一切正常，實际上它只是默默降低了频率。
- 為了提速把入口頁做成完全静態，却忘了更新連結，反而让蜘蛛反复看到相同内容。
- 只测首頁，不测带參數的入口 URL，實际被抓取的那一類頁面根本没测到。