抓取预算的另一半：时间
谈到抓取预算，多数人先想到页面数量和内链结构，但蜘蛛在一个站点上能抓多少，还取决于每一次请求要花多少时间。同一段时间窗内，响应快的站点能完成更多次抓取；响应慢的站点，并发槽位被长时间占住，单位时间的抓取量就往下掉。
换句话说，服务器响应时间不是运维指标，它同时也是一个抓取侧的变量。它不会直接决定某个页面是否被收录，但会影响蜘蛛愿不愿意把有限的额度分给这个站。
一次抓取的时间花在哪
从蜘蛛的视角看，取回一个 URL 大致经过这些阶段：DNS 解析、TCP 与 TLS 握手、发送请求、等待服务器返回首字节（TTFB）、接收 HTML，然后再按需取 CSS、JS、图片等子资源。
- 连接阶段：通常毫秒级，且有复用与缓存，波动不大。
- TTFB：服务端排队、查库、渲染、等待外部接口，慢点基本都藏在这里。
- 传输阶段：取决于 HTML 体积和压缩、CDN 回源情况。
- 子资源阶段：CSS/JS 越多越重，渲染型蜘蛛的成本越高。
真正容易失守的是 TTFB 和后两项。连接层只要证书、DNS、机房没出问题，一般是稳定值；TTFB 却会随着流量、缓存命中率、数据库状态上下浮动。
服务器慢下来之后，会连锁发生什么
- 单位时间抓取量下降：同样几分钟，快站能跑完几十个 URL，慢站可能只跑完几个，剩下的排队或被放弃。
- 抓取集中在少数入口：蜘蛛倾向先确保首页、栏目页这类高价值 URL，深处页面更晚才被排到。
- 回访间隔被拉长：当同一批 URL 反复耗时偏长，蜘蛛会降低对这部分的访问频率。
- URL 发现变慢：新链接即使已经出现在页面上，也要等上一轮抓取完成才有机会被排入队列。
- 超时被记为失败：长期没有正常返回的地址，会慢慢从抓取队列里淡出。
这些变化往往不是一夜之间出现的，而是两三周里抓取量缓慢下滑，日志上看起来只是“蜘蛛来得少了”。
几个容易被忽略的慢点
动态页面没有缓存
列表页、搜索结果页、标签聚合页常常每次请求都打一次数据库或聚合接口。蜘蛛访问的 URL 组合比真实用户多，这类页面很容易成为 TTFB 的重灾区。
页面里嵌了同步外部请求
服务端在渲染时同步调用第三方接口（汇率、库存、推荐），对方一抖动，整页就跟着慢。蜘蛛不会区分这是你的问题还是对方的问题。
缓存穿透与冷启动
蜘蛛访问的很多时候是冷门 URL，缓存里没有，正好落在最慢的那条路径上。真实用户常访问的热页面反而一直很快，容易被误判为“站点没问题”。
抓取高峰踩上业务高峰
如果站点流量本身有明显波峰，蜘蛛的抓取高峰与之重叠时，整体 TTFB 会一起被推高。
怎么定位：按模板分组，看分阶段耗时
- 先把 URL 按模板归类：首页、栏目页、详情页、列表分页、标签页，分别抽样。
- 看每组的 TTFB 中位数和尾部分布，而不是只看平均值。尾部耗时才是拖慢抓取的那部分。
- 对照蜘蛛日志中的抓取时间戳，观察同一地址两次抓取之间的间隔是否在变长。
- 把已知的慢查询、外部接口调用、未命中的缓存点列出来，逐一验证。
- 优化后用同一组 URL 复查，确认改善发生在蜘蛛实际访问的页面上，而不只是首页。
稳定比极限快更重要
一个 TTFB 稳定在 300ms 的站点，通常比平时 80ms、高峰期 3s 的站点更好抓。蜘蛛依赖的是可预测的节奏，剧烈的耗时波动会让它更谨慎地调整抓取速率。
抓取预算并不会因为一次优化而永久变大，它是站点长期响应表现的副产品。把常见模板的响应做进一个可预测的区间，比偶尔跑出一次极速更有意义。
如果暂时无法整体提速，至少先保证两点：静态资源和 HTML 可缓存，错误路径（登录、搜索、过滤参数）不要拖住正常页面的响应。这两件事做完，蜘蛛在站内的抓取路径通常会更完整一些。