抓取是有时间预算的
搜索引擎蜘蛛对每个站点、每个 URL 的抓取都有隐性的时间与资源预算。单次请求如果长时间没有响应，蜘蛛通常不会无限等待：要么在超时阈值处断开，要么降低后续对该站点的抓取频次。很多“抓取量突然掉下来”的情况，排查到最后不是入口页被封，而是响应变慢了。
值得盯的几个指标
- TTFB（首字节时间）：从请求发出到收到第一个字节，反映服务端处理与链路状况。
- 完整响应时间：包含内容传输，入口页 HTML 越大影响越明显。
- 超时与中断比例：日志中表现为请求没有状态码返回、连接被重置。
- 5xx 与 429：服务端错误和限流响应，都会让蜘蛛放慢访问节奏。
TTFB 慢通常慢在哪
入口页本身内容不多，问题往往出在生成方式：每次都查数据库、调用外部接口、渲染模板时拉远程资源。把这些去掉或做缓存，TTFB 往往能明显下降。
超时设置的取舍
服务端超时设得太长，慢请求会一直占着连接；设得太短，正常请求也可能被切断。常见做法是把应用层超时控制在几秒内，宁可快速返回一个简单页面，也不让蜘蛛干等。
并发上来之后，慢会变成连锁反应
入口页数量到一定规模，蜘蛛可能同时在多个 URL 上发起请求。如果后端处理本身较慢，连接一堆积，原本正常的页面也会一起变慢，出现“平时挺快、一抓就卡”的现象。这时要看的不是单个请求，而是整体的并发承载能力。
排查顺序可以这样排
- 先从日志取一段响应时间分布，看是普遍慢还是集中在少数 URL。
- 区分网络层与应用层：换一个探测点，看是不是链路问题。
- 检查入口页是否依赖外部资源、统计脚本或远程接口。
- 确认是某个模板、某个子域名慢，还是全部入口一致。
- 对比高峰与低谷时段，判断是容量问题还是代码问题。
常见误区
- 把慢归因于蜘蛛：蜘蛛只是按自己的策略抓，响应慢多半在自己的服务端。
- 入口页塞太多东西：大图、大段内联脚本、外链资源都会拉长响应体。
- 跳转层层转发：每多一层跳转就多一次往返，蜘蛛到达目标页的成本明显上升。
- 忽略 429 与限流：被限流后继续加投放，只会让状态更差。
几个可落地的做法
- 入口页尽量静态化或做页面级缓存，避免每次动态拼装。
- 控制 HTML 体积，非必要的资源不要放在入口页。
- 设置合理的超时与重试，避免慢请求长时间占用连接。
- 访问日志保留响应时间与状态码字段，方便回溯。
- 调整投放节奏时，同步观察抓取频次与错误率的变化。
响应速度不是“优化到极致”的问题，而是“别让蜘蛛白跑”的问题。先保证能稳定、快速地返回一个可解析的页面，再谈抓取量。
抓取数据本身有波动，单日下降不必立刻改配置。把响应时间、错误率和抓取频次放在一起看趋势，判断会稳一些。