很多站点把抓取问题归结为蜘蛛来不来，但还有一个常被忽略的变量：它来了之后，愿意为一个页面等多久。响应时间偏慢不会让抓取立刻停止，却会从整体上压缩站点每天能被抓到的页面数量。
抓取是一次有时间预算的访问
搜索引擎分配给每个站点的抓取资源并不是无限的。同一个时间段内，蜘蛛能发起的请求数量、每个请求愿意等待的时长，都有大致范围。响应越快，同样的资源能覆盖的 URL 越多；响应越慢，抓取队列推进得越慢。
可以把一次抓取拆成几步：建立连接、等待服务器返回首字节、下载完整响应体、解析内容。其中任何一步被拖长，都会占用这段时间预算。
时间到底花在哪些环节
- 连接与握手：DNS 解析慢、证书链不完整、节点距离远，都会让请求还没进到应用层就消耗掉一部分时间。
- 首字节时间：这一段最能反映后端处理速度。数据库慢查询、缓存未命中、同步调用第三方接口，通常都体现在这里。
- 响应体下载：HTML 体积过大、压缩没开、把大段数据内联进页面，都会拉长整体传输时间。
- 重定向跳转：一次访问变成三跳，等于把等待时间乘以三，而最终只有一个页面被真正抓取。
持续慢响应带来的连锁反应
单次慢并不致命，麻烦的是长期偏慢。
- 抓取频次被压低。系统判断站点响应吃力，会主动降低访问密度，把资源挪去别处。
- 抓取预算被浪费。每个慢请求占用的时间更长，能抓的 URL 总量下降，新页面排进队列的时间被推后。
- 并发通道被占住。少数几个慢页面可能同时占用多个抓取通道，影响其他页面的抓取节奏。
- 更新感知变慢。老页面重新抓取的间隔被拉长，内容改动需要更久才被反映出来。
哪些页面最容易拖后腿
通常不是首页，而是下面这几类：
- 需要实时聚合大量数据的列表页或搜索结果页；
- 没做缓存的详情页，每次访问都实时查库；
- 把全部数据内联进 HTML 的页面，体积明显偏大；
- 依赖外部接口渲染、而该接口本身不稳定的页面；
- 高峰期服务器资源吃紧时，所有页面一起变慢。
一个可执行的排查顺序
- 先分时段看日志里的响应时间分布，重点看 P95 和 P99，而不是平均值。
- 区分网络层慢还是应用层慢，比较首字节时间与总耗时之间的差距。
- 对最常被抓的模板页做压测，确认缓存是否真的命中。
- 检查是否有可以合并的重定向，把跳数缩到一跳。
- 开启压缩、精简 HTML，把不必要的数据移出首屏响应。
- 调整后按周对比抓取量的变化，不要只看单日波动。
缓存和限流要一起考虑
给蜘蛛单独放行、绕过缓存，通常并不划算。更稳妥的做法是让热门 URL 命中缓存，同时对异常的抓取密度做限流，保证正常用户和蜘蛛都不会把站点拖垮。
另外，如果站点有多个机房或 CDN 节点，不同节点的回源速度可能差别很大。蜘蛛恰好落到慢节点上，你本地测出来的速度说明不了问题。定期从多个节点各测一次，比只看一个入口更有参考价值。
响应时间不是抓取结果里的一个开关，但它决定了抓取资源能覆盖多少页面。把慢的那部分找出来修掉，往往比反复提交 URL 更有效。