响应时间是抓取链路里最先被感知的信号
蜘蛛要拿到一个入口页，第一步不是解析 HTML，而是建立连接、发出请求、等服务器返回第一字节，这个等待过程就是 TTFB。它慢的时候，蜘蛛不会给你报错，但行为会变：抓取间隔拉长、并发降低、同一批 URL 抓完的周期变长。
很多人看到日志里蜘蛛访问稀疏，第一反应是池子不够、域名太少。在换资源之前，先把入口页的响应时间确认一遍，往往成本更低。
先分清“抓取慢”到底慢在哪
抓取链路上常见的延迟点有几个：DNS 解析、TCP 与 TLS 握手、服务器排队、后端程序渲染、以及 CDN 回源。任何一环卡住，蜘蛛看到的都是同一个结论——这个站有点慢。
- DNS 解析：解析耗时过长或权威服务器不稳定，每次连接都要多等一截。
- TCP/TLS 握手：证书链不完整、未开启会话复用，握手次数会明显增加。
- 服务器排队：并发连接被占满时，新请求只能等前面的处理完。
- 后端渲染：动态生成入口页、查库、调用外部接口，都会推高首字节时间。
- 回源与中间层：CDN 未命中时回源，源站慢会直接体现在首字节上。
慢到什么程度蜘蛛会调整策略
抓取端一般有自己的超时阈值，常见做法是连接超时和读取超时分开设置。当响应长期偏慢，抓取端不会立刻把入口页彻底放弃，而是倾向于降低对本站的请求频率，把预算挪给响应更快的站点。对入口页来说，这意味着同一个入口被回访的间隔变长，新 URL 被发现的节奏也跟着慢下来。
三个最容易被忽略的延迟来源
1. 入口页的模板渲染
入口页如果每次请求都要走一遍模板引擎、查询链接列表、做随机排序，单次几十毫秒的差异在低并发时不明显，一旦抓取量上来就会被放大。静态化或加一层短时缓存，通常比直接升级服务器更有效。
2. CDN 的命中率
命中率低时，每个请求都回源，源站的压力和响应时间同时上升。可以检查缓存规则是否把带参数的入口 URL 排除了，或者缓存时间设置得过短。
3. 第三方资源与统计脚本
入口页里嵌入的外部 JS、统计代码、字体文件，如果抓取端不执行 JS，影响有限；但如果这些资源阻塞了服务端渲染或造成额外等待，同样会拖慢首字节。能用静态文字表达的内容，尽量不要依赖外部调用。
自查与优化顺序
- 从外部网络用 curl 抓取入口页，分别记录 DNS、连接、首字节、总耗时四项数据。
- 连续抓取多次，看波动情况。偶发慢和持续慢，处理方式并不相同。
- 关掉 CDN 直连源站做对比，确认延迟出在源站还是中间层。
- 检查入口页是否每次请求都动态生成，能否加缓存或做静态化。
- 确认蜘蛛 UA 的请求走的是同一套链路，没有被特殊规则绕到更慢的路径上。
观察哪些指标更靠谱
单看蜘蛛总访问量意义不大，建议结合日志里的响应时间分布、同一入口的回访间隔、以及单次会话抓取的 URL 数量一起看。如果响应时间中位数在下降，回访间隔却在拉长，那问题可能不在速度，而在内容更新或链接结构上，需要分开排查。
响应时间不是孤立指标。它和抓取预算、回访频率、URL 发现速度互相牵连，改一处最好观察一段时间再动下一处。
常见误区
- 把“蜘蛛不来”直接归因于资源不够，忽略入口页本身的速度问题。
- 认为蜘蛛没有超时提示就等于一切正常，实际上它只是默默降低了频率。
- 为了提速把入口页做成完全静态，却忘了更新链接，反而让蜘蛛反复看到相同内容。
- 只测首页，不测带参数的入口 URL，实际被抓取的那一类页面根本没测到。