蜘蛛抓取一个 URL，本质上是先建立连接、发出请求、等待服务器返回第一段数据，然后读完整个响应体。前端感知不到的服务器响应时间，会直接决定这次抓取占用了多少时间窗口。抓取量下降时，除了看状态码和 robots 规则，也值得把响应时间单独拉出来看一遍。
蜘蛛看到的“慢”，由几段时间组成
同一次抓取，时间花在不同环节，对蜘蛛的影响并不一样。
- 连接建立：DNS 解析、TCP 握手、TLS 协商。跨地区解析异常或证书链过长时，这一步会先卡住。
- 首字节时间（TTFB）：请求发出到收到第一个字节。后端排队、数据库慢查询、缓存未命中通常体现在这里。
- 响应体传输：HTML 体积、压缩是否开启、带宽是否被占满。
- 等待与重试：超过超时阈值后，这次抓取可能被放弃，改日再来。
慢页面如何消耗抓取配额
假设蜘蛛在一段时间内只愿意在某个站点上花固定的时间或连接数，一个持续 8 秒才返回的页面，占用的资源大致相当于若干个 200 毫秒就能返回的页面。问题不只是“这一页抓得慢”，而是排在它前面的 URL 也被顺延。如果慢页面集中在列表页、分类页这类入口页，影响会顺着抓取路径往下传——后续 URL 的发现和更新检查都会延后。
抓取日志里通常能看到响应时间与响应字节两个字段。把它们按 URL 分组做分位数统计，比只看平均值更容易发现少数拖后腿的页面。
排查顺序：从整体到个别
- 先确认是不是全站变慢。看整体 TTFB 的 P50 和 P95，如果两者一起抬升，多半是基础设施层面的问题。
- 再看是否集中在某类 URL。动态参数页、站内搜索页、需要实时计算的页面，通常更慢。
- 检查缓存策略。缓存命中率下降会让大量请求落到后端，抓取高峰时更明显。
- 确认是否有单页慢查询或外部接口阻塞。第三方接口超时常常连带拖慢整页。
- 最后才考虑限速与并发设置，那属于蜘蛛侧的调节，不解决服务端本身的问题。
几个容易踩的误区
- 只看平均值：平均 300 毫秒可能掩盖了少量超过 5 秒的请求。
- 把慢等同于内容多：内容体量大影响传输时间，但首字节慢通常是后端问题。
- 用前端指标代替服务端时间：浏览器里的加载时间包含资源请求与渲染，蜘蛛只关心它拿到 HTML 的那一段。
- 以为降低抓取频率就能解决：如果服务端本来就慢，降低频率只是让问题不那么集中，页面自身的响应时间不会变。
让关键路径先快起来
如果资源有限，优先保证入口页和抓取路径上被频繁引用的页面响应稳定，而不是平均用力。首页、频道页、Sitemap 里标记为高优先级的页面，慢一次影响的是一串 URL；深层孤立页面慢一次，损失相对有限。把响应时间和 URL 发现、内链结构放进同一张表里对照，判断会更接近实际情况。