搜尋蜘蛛抓取頁面时，每次請求都要等服務器返回第一個字节。這個等待時間就是 TTFB（Time To First Byte）。它不只影响用戶体驗，也會影响蜘蛛在單位時間内能抓多少頁面。TTFB 長期偏高的站点，抓取频次和覆盖速度往往不理想。
TTFB 和抓取节奏的關系
蜘蛛的抓取资源有限。假设一個站点平均响應時間是 200 毫秒，另一個是 2 秒，同样的抓取窗口里，前者能請求的頁面數量會多很多。响應慢還會增加超时和连接中断的概率，蜘蛛可能暂时降低對该站点的抓取频次。
需要說明的是，TTFB 不是排名因素，也不保證收錄。它影响的是抓取效率，間接影响新内容被發現的速度。所以優化目标是让服務器稳定、快速地返回内容，而不是追求极限數字。
哪些环节會推高 TTFB
- 資料库查询慢：列表頁、詳情頁每次請求都做复杂查询，没有索引或缓存。
- 頁面缓存缺失：每次訪問都重新生成 HTML，動態逻辑偏重。
- 外部接口阻塞：頁面渲染时同步調用第三方接口，對方响應慢，自己的頁面也跟着慢。
- 服務器资源不足：CPU、内存、连接數接近上限，請求排队。
- 重定向過多：一次訪問经過多次 301 或 302，增加往返時間。
- DNS 解析和 TLS 握手慢：域名解析不稳定或證书鏈配置不佳。
排查：先看日誌，再做測試
服務器日誌里通常有請求耗时字段。可以按 URL 分组，看哪些目錄或模板的平均响應時間明顯偏高。重点观察 P95 或 P99，而不是只看平均值。平均值正常但長尾很慢，同样會拖累蜘蛛。
手動測試可以用 curl -w 查看各阶段耗时，也可以借助浏览器開發者工具的 Network 面板。重点關注 DNS、连接、TLS、等待响應這几個阶段，判断瓶颈在解析、網絡還是應用本身。
可以落地的優化方向
- 開啟頁面缓存或對象缓存，减少重复計算。對蜘蛛经常抓取的列表頁和詳情頁優先處理。
- 检查慢查询，补充必要索引，避免在循环里查資料库。
- 把非關键的外部調用改為异步，或者加短時間缓存，不要让第三方接口拖住整頁响應。
- 使用 CDN 分發静態资源，回源压力會小一些。動態頁面也可以考虑邊缘缓存，但要注意登入態和個性化内容。
- 啟用 HTTP/2 或 HTTP/3，合理配置 keep-alive，减少连接建立開销。
- 開啟 Gzip 或 Brotli 压缩，降低传輸体积，但不要压缩已经压缩過的图片和视频。
- 清理不必要的重定向鏈，让蜘蛛一次請求到位。
優化时容易忽略的两点
第一，不要只優化首頁。蜘蛛抓取最多的是内容頁和列表頁，這些頁面的响應時間更值得關注。第二，優化後要观察错誤率。如果為了提速而频繁出現 5xx，反而會让蜘蛛降低抓取。稳定比單次快更重要。
TTFB 優化不是一次性任務。把它放進日常监控，结合抓取日誌一起看，才能判断調整是否真的有效。
建议持續观察的指标
- 平均 TTFB 和 P95 响應時間，按栏目或模板分组。
- 5xx 和超时請求的比例。
- 搜尋蜘蛛的抓取频次與每日抓取頁面數。
- 新發布内容的發現時間，從提交到首次被抓的間隔。
這些指标不需要每天细看，但至少按月對比。如果响應時間下降後，蜘蛛抓取量没有變化，也不必焦虑，抓取策略還受站点權重、内容更新频率等因素影响。把服務器响應保持在合理范围，是站点运营的基础工作之一。