做站点运营时，大家习惯盯着内容和链接，但页面能不能被顺利抓取，很多时候卡在更前面的一环：服务器响应速度。爬虫是按队列工作的，一个地址的响应没有结束，它很难痛快地转向下一个。如果单页动辄几秒，甚至超时断开，抓取效率就会明显下降，原本能被发现的页面也可能被排到很后面。
先确认慢在哪一段
用 curl 的耗时输出或浏览器开发者工具的时间线，把一次请求拆开看：DNS 解析、TCP 连接、TLS 握手、等待首字节（TTFB）、内容传输。多数站点的瓶颈在 TTFB，也就是服务器真正开始吐数据之前的等待。如果 TTFB 就占了两三秒，后面传得再快意义也有限。
值得留意的几个指标
- TTFB：最能反映后端处理效率，通常优先关注；
- 总耗时：包含内容下载，页面越重差异越明显；
- 状态码分布：偶尔冒出 5xx 或超时，说明稳定性存在问题；
- 并发下的表现：单次请求快，不代表同时来几十个请求还快。
也可以横向对比：首页快、详情页慢，问题多半出在业务逻辑；静态文件快、动态页慢，常和数据库或缓存有关；移动端和桌面端都慢，则更可能是服务器整体负载偏高。
常见的拖慢原因
- 详情页每次请求都查库，且没有做页面级缓存或查询缓存；
- 渲染时同步调用第三方接口，接口一慢整页跟着慢；
- 会话、统计、推荐等逻辑在首屏阻塞执行；
- 服务器 CPU、内存、磁盘 IO 长期接近上限，高峰期排队；
- 带宽或出口有限，大文件把连接占满；
- 防火墙、WAF、限流规则对爬虫请求做了额外延迟或拦截。
抓取预算不是无限的
搜索引擎给每个站点分配的抓取资源是有限的。响应快、更新稳定的站点，单位时间里能抓更多地址；响应慢的站点，同样的时间只能覆盖很少的页面。时间一长，新内容进入索引的速度会变慢，一些深层页面可能长期排不上队。
与其反复提交 Sitemap 催促，不如先把 TTFB 从三秒压到几百毫秒，效果往往更直接。
可以按这个顺序排查处理
- 先建立基线：连续几天记录首页、栏目页、详情页的 TTFB 和总耗时，区分高峰期与低谷期。
- 关掉不必要的同步调用，把统计、推荐、评论加载改成异步或延后执行。
- 给详情页加缓存，热点内容走内存或静态化，减少重复查库。
- 检查慢查询日志，给常用查询补上索引，避免全表扫描。
- 静态资源交给 CDN，减轻源站的带宽和连接压力。
- 核对服务器的限流与安全策略，确认正常爬虫不会被误伤或刻意延迟。
- 设置超时兜底，避免个别请求长时间挂起占用连接。
把它变成日常监控项
响应时间适合做成长期指标，而不是出问题才去看。可以用简单的定时脚本或监控服务，按分钟或按小时记录关键页面的状态码和耗时，超过阈值就告警。观察时注意区分：是偶发抖动，还是持续变慢；是全部页面，还是某一类页面。前者可能是临时负载，后者往往指向具体的代码或查询。
需要提醒的是，调优的目标是让页面稳定、及时地返回内容，而不是追求某个绝对数字。不同站点的架构差别很大，先找到自己的瓶颈，再一点点改，比一次性大改更稳妥。