入口頁能不能被顺利抓取，很多时候不是内容問题，而是“服務器多久回话”的問题。蜘蛛的抓取队列是有限资源，超时和慢响應會直接消耗這份预算。這篇只聊一件事：响應速度，以及 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，把入口頁砍到没有可用内容，反而得不偿失。
把响應速度当作基础设施的一部分来维護，入口頁的抓取节奏才不會被服務器拖後腿。每次改動上线後，给它一段观察期再判断效果，比一次性大改更稳妥。