很多抓取异常最后都会落到同一个原因上：服务器响应太慢。页面本身没问题，robots 没拦，链接也在，但蜘蛛每次来都要等上几秒甚至超时，次数多了，来访自然就少了。这篇文章整理一套以响应时间为切入点的自查方法，重点是量化和对比，而不是凭感觉说「好像有点慢」。
为什么响应时间值得单独检查
蜘蛛对单个站点能同时发起的请求数是有限的，单次请求也不会无限等待。当响应时间从几百毫秒涨到两三秒，同样的时间窗口里能抓完的页面数量会明显下降；如果出现超时中断，这部分请求还会被记为失败，蜘蛛后续可能主动降低访问频次。所以响应时间不只是用户体验话题，它同时决定了抓取的吞吐量。
先分清几个容易混淆的指标
- 首字节时间（TTFB）：从请求发出到收到第一个字节，反映服务端处理速度，包含 DNS 解析、连接建立、应用逻辑、数据库查询等环节。
- 内容下载时间：首字节之后传输完整 HTML 的耗时，和页面体积、压缩方式、CDN 有关。
- 超时与 5xx 比例：比平均值更能说明问题，平均值很容易被大量正常请求稀释掉。
- 并发承载能力：单请求很快，但并发一上来就排队，同样会拖慢抓取。
- 静态页与动态页的差异：列表页、筛选页、带参数的页面通常比文章页慢，需要分开统计。
常见的拖慢原因
按排查成本从低到高，可以先看这几类：
- 数据库慢查询：列表页或标签页在每次访问时做全表扫描、模糊匹配；
- 同步调用第三方接口：页面渲染时才去请求支付、推荐、天气等外部服务，对方一慢，整页就慢；
- 动态生成图片或缩略图：每次请求都实时裁剪，且没有缓存；
- 日志同步写盘、调试开关未关闭：上线后仍开着详细日志；
- 缺少缓存层：同一份数据每次访问都要重新计算；
- DNS 解析与证书握手异常：首次连接耗时偏高，或证书链不完整导致反复重试。
一份可执行的自查清单
- 用 curl 或浏览器开发者工具，分别记录首页、栏目页、详情页的首字节时间，取多次访问的中位数；
- 在服务器日志里按状态码和响应时间排序，找出最慢的那几十个地址，观察是否有共同特征；
- 单独统计蜘蛛请求中超时和 5xx 的占比，并把 HTML 与静态资源分开看；
- 对比加缓存前后同一地址的响应时间，确认缓存命中的比例；
- 做一次简单的并发测试，确认站点在正常抓取强度下是否出现排队；
- 检查上线开关、调试模式、详细日志是否遗留未关；
- 把结论整理成表格，隔一到两周复测一次。
记录比单次测速更重要
单次测出的数字受网络波动影响很大，容易出现「今天快了，明天又慢」的错觉。更实用的做法是固定几个采样地址和采样时间，把首字节时间、状态码、响应大小记下来，做成一条简单的时间线。站点改版、上新活动、调整缓存策略之后，对照这条时间线就能看出变化来自哪里。
响应时间不需要追求极致，只要稳定在一个合理区间、没有大量超时，抓取节奏基本不会被打乱。真正需要警惕的是突然变慢和持续变慢，而不是某个时刻的峰值。
最后提醒一句：响应时间是结果，不是原因。找到究竟是数据库、外部依赖还是缓存策略造成的，再决定怎么改，比盲目加机器更有效。