抓取是有時間预算的
搜尋引擎蜘蛛對每個站点、每個 URL 的抓取都有隐性的時間與资源预算。單次請求如果長時間没有响應，蜘蛛通常不會無限等待：要么在超时阈值處断開，要么降低後續對该站点的抓取频次。很多“抓取量突然掉下来”的情况，排查到最後不是入口頁被封，而是响應變慢了。
值得盯的几個指标
- TTFB（首字节時間）：從請求發出到收到第一個字节，反映服務端處理與鏈路状况。
- 完整响應時間：包含内容传輸，入口頁 HTML 越大影响越明顯。
- 超时與中断比例：日誌中表現為請求没有狀態碼返回、连接被重置。
- 5xx 與 429：服務端错誤和限流响應，都會让蜘蛛放慢訪問节奏。
TTFB 慢通常慢在哪
入口頁本身内容不多，問题往往出在生成方式：每次都查資料库、調用外部接口、渲染模板时拉遠程资源。把這些去掉或做缓存，TTFB 往往能明顯下降。
超时設定的取舍
服務端超时设得太長，慢請求會一直占着连接；设得太短，正常請求也可能被切断。常见做法是把應用层超时控制在几秒内，宁可快速返回一個简單頁面，也不让蜘蛛干等。
並發上来之後，慢會變成连鎖反應
入口頁數量到一定規模，蜘蛛可能同时在多個 URL 上發起請求。如果後端處理本身較慢，连接一堆积，原本正常的頁面也會一起變慢，出現“平时挺快、一抓就卡”的現象。這时要看的不是單個請求，而是整体的並發承载能力。
排查顺序可以這样排
- 先從日誌取一段响應時間分布，看是普遍慢還是集中在少數 URL。
- 区分網絡层與應用层：換一個探测点，看是不是鏈路問题。
- 检查入口頁是否依赖外部资源、統計脚本或遠程接口。
- 確認是某個模板、某個子域名慢，還是全部入口一致。
- 對比高峰與低谷时段，判断是容量問题還是代碼問题。
常见誤区
- 把慢归因于蜘蛛：蜘蛛只是按自己的策略抓，响應慢多半在自己的服務端。
- 入口頁塞太多東西：大图、大段内联脚本、外鏈资源都會拉長响應体。
- 跳轉层层轉發：每多一层跳轉就多一次往返，蜘蛛到達目标頁的成本明顯上升。
- 忽略 429 與限流：被限流後繼續加投放，只會让狀態更差。
几個可落地的做法
- 入口頁尽量静態化或做頁面級缓存，避免每次動態拼装。
- 控制 HTML 体积，非必要的资源不要放在入口頁。
- 設定合理的超时與重试，避免慢請求長時間占用连接。
- 訪問日誌保留响應時間與狀態碼字段，方便回溯。
- 調整投放节奏时，同步观察抓取频次與错誤率的變化。
响應速度不是“優化到极致”的問题，而是“別让蜘蛛白跑”的問题。先保證能稳定、快速地返回一個可解析的頁面，再谈抓取量。
抓取資料本身有波動，單日下降不必立刻改配置。把响應時間、错誤率和抓取频次放在一起看趋势，判断會稳一些。