很多站点在流量正常时並不關注响應時間，直到某天發現蜘蛛来得少了、新頁面迟迟没動静，才回头去翻日誌。抓取本质上是一件很看時間成本的事：蜘蛛在一個頁面上多等一秒，它能走的頁面就少一個。响應速度不只影响用戶体驗，也直接决定蜘蛛在你的站上能走多遠。
一次抓取的時間花在哪
- 连接建立：DNS 解析、TCP 握手、TLS 协商，這段和服務器性能關系不大，但受机房位置、CDN 节点影响明顯。
- 首字节時間（TTFB）：請求發出到收到第一個字节，基本由後端决定，是排查时最先该看的指标。
- 内容传輸：HTML 從服務器传到蜘蛛手里，体积越大、出口带宽越紧，這一段越長。
- 解析與渲染：蜘蛛還要构建 DOM、执行脚本、取必要的子资源，這部分慢通常出在前端。
响應慢會带来哪些连鎖反應
- 蜘蛛有自己的等待上限，超时後這次抓取就算失敗，頁面当次的内容不會被拿到。
- 抓到失敗或半截内容，蜘蛛容易判断這一頁不值得频繁来，後續抓取频率大概率會降。
- 抓取時間被慢頁面吃掉，分给其他頁面的額度就少了，新 URL 發現和更新重抓都會往後排。
- 慢請求會占用服務器连接和進程，高峰期越慢越堵，容易形成自我强化的拥堵。
要注意的是，蜘蛛並不會因為你偶尔慢一次就永久降低抓取，它更看長期表現和整体比例。但如果慢請求占比持續偏高，抓取节奏的收缩是比較常见的現象。
该盯哪些指标
- 蜘蛛請求的平均响應時間和 P95，平均值正常但長尾很慢，同样會拖累抓取。
- 超时與 5xx 在蜘蛛請求中的占比，這是最直接的信号。
- 單次抓取的完整下载時間，而不只是首字节。
- 頁面 HTML 体积，動辄几百 KB 的 DOM 會让解析阶段明顯變長。
先分清是全局慢還是只對蜘蛛慢
把日誌里带蜘蛛 UA 的請求單獨拎出来，算一遍响應時間分布，再和普通用戶請求做對比。
- 两類請求都慢：多半是後端、資料库或带宽的問题。
- 只有蜘蛛慢：检查是否有限速規則、WAF 策略，或者线路與地区的差异。
- 只有某個时段慢：對照备份、报表、定时任務的時間点，看看是不是撞在一起。
可以動手做的几件事
- 给列表頁、文章頁加缓存层，把動態查询结果缓存住，减少每次請求都穿透到資料库。
- 把明顯可以静態化的頁面静態化，尤其是訪問量大的入口頁。
- 控制 HTML 体积，做好压缩，去掉不需要的内联脚本和冗余标簽，减少 DOM 深度。
- 高峰期给蜘蛛設定合理的並發上限，而不是直接拒绝；拒绝容易让抓取节奏更乱。
- 把定时任務错峰，尽量避開蜘蛛活跃的时段。
- 用 CDN 分担静態资源，让回源請求集中在真正的頁面上。
响應時間不是優化一次就能一劳永逸的事。改完之後隔一两周再回来看日誌里的分布，比看單次測試结果更有意义。
小结
蜘蛛的等待是有邊界的，頁面响應速度决定了它能不能把该拿的内容拿完整。與其纠结蜘蛛多久回来一次，不如先把平均响應時間和長尾請求压下来。抓取顺畅之後，URL 發現和更新重抓這些环节才谈得上有节奏。