蜘蛛抓取是有成本的。同一个站点，服务器响应快，蜘蛛在同样时间里能多取几十上百个页面；响应慢，抓取队列就会往后排，新内容上线后可能迟迟不被访问。很多站点内容本身没问题，卡点却在服务器端——每次请求要等一两秒才吐出第一个字节。
为什么响应速度会直接影响抓取
搜索引擎爬虫通常会为每个站点分配一定的并发数和超时阈值。当请求长时间没有响应、或者频繁超时，爬虫会主动降低对该站的抓取频率，避免把资源耗在一个慢站上。抓到一半断开、只取到部分内容的情况，也会让页面被判定为不稳定。
抓取预算不是固定的配额，它更像一个随响应质量浮动的信用额度：响应稳定快速，额度就宽裕。
先量出真实的首字节时间
TTFB（Time To First Byte）指从发出请求到收到响应第一个字节的时间，它包含了 DNS 解析、连接建立、服务器处理、后端渲染等环节。要判断问题出在哪儿，得把这几段分开看。
几个常用的测量方式
- 浏览器开发者工具的 Network 面板，看每个请求的 Waiting（TTFB）一列，注意区分平均值和个别页面。
- 命令行用 curl 输出各阶段耗时，例如 curl -o /dev/null -s -w '%{time_starttransfer}' URL，可以批量跑几个有代表性的页面。
- 服务器访问日志里的响应时间字段，能看出慢请求集中在哪些路径、哪些时段。
- 监控工具按小时采样，比一次性测速更能反映真实波动。
测的时候要区分「只有动态页面慢」还是「整站都慢」。如果只有带查询参数的页面慢，问题多半在后端；如果连静态图片都慢，可能是带宽、DNS 或前置链路的问题。
常见的拖慢原因
- 数据库缺少合适索引，列表页每次都要全表扫描。
- 页面渲染时同步调用外部接口，第三方一慢，整页就卡住。
- 未开启页面缓存或缓存命中率低，同一份内容反复计算。
- 单台服务器扛全部流量，爬虫和真实用户互相抢资源。
- 日志同步写入频繁，磁盘 IO 被打满。
- 图片或附件未压缩，出口带宽被大文件占满。
可以按这个顺序优化
- 先加一层页面缓存，把不常变的列表页、详情页缓存几十秒到几分钟，收益通常最直接。
- 给高频查询字段补索引，尤其是列表排序和时间筛选用到的字段。
- 把第三方调用改成异步或加超时与降级，避免一个接口拖垮整页。
- 静态资源交给 CDN，服务器只处理动态请求。
- 如果已经被爬虫高频访问，可以在 robots.txt 或服务器层面对低价值路径限流，把资源留给正文页。
- 最后再考虑升级配置，顺序反了容易花了钱没解决问题。
优化之后怎么验证
不要只看某一次测速变快了。至少观察一到两周：服务器日志中的中位响应时间是否下降，抓取总量和新增页面的被访问速度是否回升，超时和 5xx 是否减少。如果响应时间下降但抓取量没变化，说明瓶颈可能在别处，比如内链入口太少或站点地图没有覆盖新页面。
另外注意别走到另一个极端：为了压低 TTFB 把缓存时间设得过长，导致内容更新后访客长时间看到旧页面；或者缓存粒度过粗，把不同用户的状态混在一起。速度是手段，稳定和内容准确才是目的。