很多站点把抓取問题归结為蜘蛛来不来，但還有一個常被忽略的變量：它来了之後，愿意為一個頁面等多久。响應時間偏慢不會让抓取立刻停止，却會從整体上压缩站点每天能被抓到的頁面數量。
抓取是一次有時間预算的訪問
搜尋引擎分配给每個站点的抓取资源並不是無限的。同一個時間段内，蜘蛛能發起的請求數量、每個請求愿意等待的时長，都有大致范围。响應越快，同样的资源能覆盖的 URL 越多；响應越慢，抓取队列推進得越慢。
可以把一次抓取拆成几步：建立连接、等待服務器返回首字节、下载完整响應体、解析内容。其中任何一步被拖長，都會占用這段時間预算。
時間到底花在哪些环节
- 连接與握手：DNS 解析慢、證书鏈不完整、节点距离遠，都會让請求還没進到應用层就消耗掉一部分時間。
- 首字节時間：這一段最能反映後端處理速度。資料库慢查询、缓存未命中、同步調用第三方接口，通常都体現在這里。
- 响應体下载：HTML 体积過大、压缩没開、把大段資料内联進頁面，都會拉長整体传輸時間。
- 重定向跳轉：一次訪問變成三跳，等于把等待時間乘以三，而最终只有一個頁面被真正抓取。
持續慢响應带来的连鎖反應
單次慢並不致命，麻烦的是長期偏慢。
- 抓取频次被压低。系統判断站点响應吃力，會主動降低訪問密度，把资源挪去別處。
- 抓取预算被浪費。每個慢請求占用的時間更長，能抓的 URL 總量下降，新頁面排進队列的時間被推後。
- 並發通道被占住。少數几個慢頁面可能同时占用多個抓取通道，影响其他頁面的抓取节奏。
- 更新感知變慢。老頁面重新抓取的間隔被拉長，内容改動需要更久才被反映出来。
哪些頁面最容易拖後腿
通常不是首頁，而是下面這几類：
- 需要實时聚合大量資料的列表頁或搜尋结果頁；
- 没做缓存的詳情頁，每次訪問都實时查库；
- 把全部資料内联進 HTML 的頁面，体积明顯偏大；
- 依赖外部接口渲染、而该接口本身不稳定的頁面；
- 高峰期服務器资源吃紧时，所有頁面一起變慢。
一個可执行的排查顺序
- 先分时段看日誌里的响應時間分布，重点看 P95 和 P99，而不是平均值。
- 区分網絡层慢還是應用层慢，比較首字节時間與總耗时之間的差距。
- 對最常被抓的模板頁做压测，確認缓存是否真的命中。
- 检查是否有可以合並的重定向，把跳數缩到一跳。
- 開啟压缩、精简 HTML，把不必要的資料移出首屏响應。
- 調整後按周對比抓取量的變化，不要只看單日波動。
缓存和限流要一起考虑
给蜘蛛單獨放行、绕過缓存，通常並不划算。更稳妥的做法是让热门 URL 命中缓存，同时對異常的抓取密度做限流，保證正常用戶和蜘蛛都不會把站点拖垮。
另外，如果站点有多個机房或 CDN 节点，不同节点的回源速度可能差別很大。蜘蛛恰好落到慢节点上，你本地测出来的速度說明不了問题。定期從多個节点各测一次，比只看一個入口更有參考價值。
响應時間不是抓取结果里的一個開關，但它决定了抓取资源能覆盖多少頁面。把慢的那部分找出来修掉，往往比反复提交 URL 更有效。