蜘蛛抓一个页面，第一步不是解析内容，而是等服务器把第一段字节送回来。这段时间如果太长，后面的解析、渲染、内链发现都会被往后推。不少站点把精力放在内容质量和结构上，却忽略了响应速度这个前置条件。

先搞清楚 TTFB 量的是什么

TTFB 指首字节时间，即从请求发出到客户端收到第一个字节所经过的时间。它不是单一环节，而是一串动作的叠加：

• DNS 解析与 TCP 连接建立
• TLS 握手（HTTPS 站点）
• 请求到达服务端并排队
• 后端程序处理、数据库查询、模板渲染
• 响应开始回传

所以 TTFB 偏高时，先别急着换服务器，要判断到底是哪一段慢。

蜘蛛为什么在意这一秒半秒

搜索引擎给每个站点的抓取资源是有限的，通常称为抓取预算。同样的时间窗口内，响应慢的站点能抓完的页面数量自然更少。更麻烦的是，超时或响应不稳定的地址会被降低抓取优先级，反复超时还可能让蜘蛛减少访问频次。对于栏目多、页面量大的站点，这个差异会被放大。

几种低成本的自查方式

命令行与浏览器工具

• 用 curl 的 -w 参数输出首字节耗时，同一地址测 5 到 10 次，看波动而不是单次值
• 浏览器开发者工具的 Network 面板，关注 Waiting 这一列的耗时
• PageSpeed Insights 之类的工具，注意区分实验室数据与真实用户数据

从日志与监控里看趋势

• 关注蜘蛛访问的响应状态码与耗时分布，而不只是全站平均响应时间
• 把 5xx、超时、连接重置单独统计，它们对抓取的影响比单纯变慢更大
• 对比高峰与低峰时段的差异，确认是资源不足还是程序本身的问题

常见的拖慢原因

• 每次请求都实时查库，且缺少索引或查询缓存
• 页面内同步调用第三方接口，对方一慢整页都慢
• 未开启页面缓存或对象缓存，动态渲染成本偏高
• 未启用压缩，也没有连接复用手段
• 服务器资源吃紧，CPU 或内存长期跑在高位
• 距离远且没有 CDN，握手环节就先消耗掉一部分时间

优化顺序建议

1. 先记录基线数据，明确当前的中位 TTFB 与错误率，方便后面比对
2. 从缓存入手：页面缓存、对象缓存、查询缓存，收益通常最直接
3. 排查慢查询与同步外部调用，能异步的异步，能预取的预取
4. 再考虑接入 CDN、开启压缩与更新的传输协议，改善网络环节
5. 每次只改一类，改完观察一段时间日志，确认没有引入新的 5xx

响应快并不等于会被收录。它更像一张入场券，解决的是蜘蛛愿不愿意来、能不能顺利抓完的问题。

别只盯一个数字

TTFB 本身有天然波动，受网络、机房、时段影响。与其追求某个绝对值，不如盯住三件事：中位数是否稳定、慢请求占比是否下降、蜘蛛抓取时的错误率是否降低。把这几项和抓取量、索引量放在同一张表里看，才能判断改动是否真的有效。

最后提醒一句，调整服务器参数或缓存策略之前，先准备好回滚方案。站点运营里的很多工作，价值不在于某一次优化做得多漂亮，而在于状态能不能长期保持稳定。