蜘蛛抓取一個 URL，本质上是先建立连接、發出請求、等待服務器返回第一段資料，然後讀完整個响應体。前端感知不到的服務器响應時間，會直接决定這次抓取占用了多少時間窗口。抓取量下降时，除了看狀態碼和 robots 規則，也值得把响應時間單獨拉出来看一遍。
蜘蛛看到的“慢”，由几段時間组成
同一次抓取，時間花在不同环节，對蜘蛛的影响並不一样。
- 连接建立：DNS 解析、TCP 握手、TLS 协商。跨地区解析異常或證书鏈過長时，這一步會先卡住。
- 首字节時間（TTFB）：請求發出到收到第一個字节。後端排队、資料库慢查询、缓存未命中通常体現在這里。
- 响應体传輸：HTML 体积、压缩是否開啟、带宽是否被占满。
- 等待與重试：超過超时阈值後，這次抓取可能被放弃，改日再来。
慢頁面如何消耗抓取配額
假设蜘蛛在一段時間内只愿意在某個站点上花固定的時間或连接數，一個持續 8 秒才返回的頁面，占用的资源大致相当于若干個 200 毫秒就能返回的頁面。問题不只是“這一頁抓得慢”，而是排在它前面的 URL 也被顺延。如果慢頁面集中在列表頁、分類頁這類入口頁，影响會顺着抓取路径往下传——後續 URL 的發現和更新检查都會延後。
抓取日誌里通常能看到响應時間與响應字节两個字段。把它們按 URL 分组做分位數統計，比只看平均值更容易發現少數拖後腿的頁面。
排查顺序：從整体到個別
- 先確認是不是全站變慢。看整体 TTFB 的 P50 和 P95，如果两者一起抬升，多半是基础设施层面的問题。
- 再看是否集中在某類 URL。動態參數頁、站内搜尋頁、需要實时計算的頁面，通常更慢。
- 检查缓存策略。缓存命中率下降會让大量請求落到後端，抓取高峰时更明顯。
- 確認是否有單頁慢查询或外部接口阻塞。第三方接口超时常常连带拖慢整頁。
- 最後才考虑限速與並發設定，那属于蜘蛛侧的調节，不解决服務端本身的問题。
几個容易踩的誤区
- 只看平均值：平均 300 毫秒可能掩盖了少量超過 5 秒的請求。
- 把慢等同于内容多：内容体量大影响传輸時間，但首字节慢通常是後端問题。
- 用前端指标代替服務端時間：浏览器里的加载時間包含资源請求與渲染，蜘蛛只關心它拿到 HTML 的那一段。
- 以為降低抓取频率就能解决：如果服務端本来就慢，降低频率只是让問题不那么集中，頁面自身的响應時間不會變。
让關键路径先快起来
如果资源有限，優先保證入口頁和抓取路径上被频繁引用的頁面响應稳定，而不是平均用力。首頁、频道頁、Sitemap 里标记為高優先級的頁面，慢一次影响的是一串 URL；深层孤立頁面慢一次，损失相對有限。把响應時間和 URL 發現、内鏈结构放進同一張表里對照，判断會更接近實际情况。