前面几篇聊過抓取失敗、重定向和抓取预算，這一篇把镜头對准服務器本身的响應速度。蜘蛛不會因為一次慢就放弃站点，但持續的慢會實實在在改變它来你站点的频率和深度。
蜘蛛為什么在意响應時間
抓取是一個排队的過程，蜘蛛在單位時間内能取回的頁面數是有限的。当你的服務器處理一個請求需要 2 秒而不是 200 毫秒，同样的並發下，它在這段時間里能拿到的頁面就變少了。通常會出現两種结果：降低對你站点的抓取速率，或者把资源挪给响應更快的站点。前者让你更新被發現的节奏變慢，後者更难受。
慢在哪一段，日誌里能看到
不是所有“慢”都是同一回事。服務器日誌往往只记總耗时，需要配合其他資料才能分清：
- 连接阶段慢：DNS 解析、TCP 握手、TLS 握手耗时偏高，常见于线路或證书配置問题。
- 首字节慢（TTFB）：請求到了，應用迟迟不返回。通常是資料库查询、外部接口調用、頁面生成阻塞。
- 传輸阶段慢：首字节很快，但頁面体积大、带宽打满，整体下载時間被拉長。压缩和资源体积在這里起作用。
三類問题的處理方式完全不同：线路問题要查节点和配置，TTFB 問题要查後端，传輸問题要從体积入手。混在一起判断，容易改错地方。
超时阈值之外的後果
蜘蛛一般會给自己设一個等待上限。超過這個上限，它记錄下来的就不是“慢”，而是失敗。失敗一次不致命，但如果同一批 URL 反复超时，這些地址在你站点里的可抓取印象會變差，後續回訪會更谨慎。更麻烦的是，超时往往發生在動態、需要計算的頁面上，也就是你最希望被收錄的那部分。
抓取速率會自己下調
很多站長會观察到類似現象：某段時間服務器压力大，日誌里蜘蛛請求數明顯下降，之後即使頁面恢复正常，抓取量也要過一段時間才回到原来的水平。這是抓取速率被調低的典型表現。它不會立刻恢复，通常需要一段稳定的快速响應期。
可以做的几件事
- 把稳定内容放到缓存前面：不常變的内容走缓存或静態化，让蜘蛛拿到的是几毫秒的响應。
- 给動態頁面设上限：資料库慢查询加超时保護，宁可返回简化内容，也不要让請求一直挂着。
- 压缩與懒加载分清主次：首屏文字優先送達，图片和非關键脚本不必拖慢首字节。
- 別让防護策略誤伤：限流和驗證頁面如果作用在蜘蛛身上，通常表現為狀態碼異常，而不是單纯的變慢。
观测方式
把服務器日誌按小时聚合，盯住三组數字：蜘蛛請求總數、平均响應時間、超时或非 2xx 占比。三者一起看，才能判断是“来得少了”，還是“来得不少但拿到的東西變差了”。如果只是响應時間上升而請求數没變，問题多半還在你這邊；如果請求數先掉，說明蜘蛛已经調整了节奏。
响應速度是抓取表現里少數你能直接控制的因素之一。它不保證排名结果，但會明顯影响蜘蛛愿意花多少時間在你的站点上。
最後提醒一点：不要為了让蜘蛛看到快頁面，而给它返回和普通用戶不同的内容。更稳妥的做法是把整站變快，或者至少让需要被抓取的關键頁面保持稳定响應。