入口页能不能被顺利抓取，很多时候不是内容问题，而是“服务器多久回话”的问题。蜘蛛的抓取队列是有限资源，超时和慢响应会直接消耗这份预算。这篇只聊一件事：响应速度，以及 TTFB 该控制在什么水平。
蜘蛛眼里的“响应速度”是什么
从蜘蛛发起请求到收到第一个字节的时间，就是常说的 TTFB。它包含 DNS 解析、TCP 与 TLS 握手、服务器处理、后端渲染等环节。蜘蛛通常有超时阈值，超过就可能断开连接，并记下一次失败。
要注意 TTFB 只是第一字节，后面还有完整 HTML 的传输时间。但在多数情况下，TTFB 慢，整体就慢，两者很少脱节。
慢响应会带来哪些连锁反应
- 抓取配额被浪费：同样一段时间，快站能抓一百个页面，慢站可能只抓二十个。
- 超时记录累积：连续超时可能让蜘蛛降低对该站的抓取频次。
- 并发连接被占满：一个慢请求占住连接，后面的 URL 只能排队。
- 用户体验同步变差：蜘蛛感受到的慢，用户同样感受得到。
耗时通常花在哪几个环节
握手与网络层
跨地域、跨机房的物理延迟；HTTPS 握手多一次往返；没有开启 keep-alive 时，每个请求都要重新握手。
服务端处理
动态生成页面、查询数据库、调用第三方接口、模板渲染，任何一步卡住，首字节就迟迟不出现。
输出与压缩
HTML 体积过大、未开启 gzip 或 brotli，传输阶段会明显拉长时间。
把 TTFB 压下来的实操顺序
- 先测再改：用 curl 的耗时输出或访问日志里的响应时间字段，按小时统计 P50 与 P95，不要只看平均值。
- 开启连接复用：启用 keep-alive，减少重复握手带来的固定开销。
- 入口页尽量静态化：能整页缓存的就整页缓存，命中缓存时直接返回，不必走完整逻辑。
- 挪走阻塞项：第三方接口调用改成异步或本地缓存，别让它挡在 HTML 输出前面。
- 开启压缩：gzip 或 brotli 打开，顺手精简不必要的内联代码。
- 排查慢查询：检查索引缺失、锁等待、连接池耗尽这类典型问题。
- 用 CDN 承接静态部分：回源只处理真正需要动态生成的内容。
阈值参考与监控方式
经验上，TTFB 稳定在 200 毫秒以内比较理想，500 毫秒以内多数场景还能接受，超过 1 秒就该排查了。这不是硬标准，具体取决于机房位置和蜘蛛来源。建议按 URL 分组统计，把入口页和普通内容页分开看，避免互相掩盖。
响应时间的目标不是“最快”，而是“稳定”。偶发的尖峰比持续偏慢更容易触发降频。
几个常见误区
- 只优化首页，入口页完全没纳入监控。
- 把 CDN 命中时的耗时和回源响应混在一起看，得出错误结论。
- 用平均值掩盖尾延迟，直到某天抓取量突然下滑才发现问题。
- 为了压低 TTFB，把入口页砍到没有可用内容，反而得不偿失。
把响应速度当作基础设施的一部分来维护，入口页的抓取节奏才不会被服务器拖后腿。每次改动上线后，给它一段观察期再判断效果，比一次性大改更稳妥。