入口頁的响應速度，是蜘蛛池里最容易被忽略、又最容易拖後腿的一环。内容、連結、模板都做得差不多的时候，服務器回得慢，抓取节奏就會明顯變差。
為什么 TTFB 比頁面大小更值得先看
TTFB（首字节時間）指的是蜘蛛發出請求到收到第一個字节之間的間隔。它包含了 DNS、连接建立、後端處理和資料库查询這些环节。頁面体积再大，只要開始返回了，剩下的只是传輸問题；而 TTFB 慢，意味着蜘蛛一直在等待，连接被占着，抓取线程没法释放。
對蜘蛛池入口頁這種轻量頁面来说，HTML 通常很小，真正的時間几乎都花在 TTFB 上。所以看速度，先看這一項，而不是盯着整頁加载時間。
蜘蛛碰到慢响應會怎么處理
- 單次超时：直接放弃這次抓取，日誌里能看到中断或 5xx。
- 连續變慢：降低该路径的抓取频次，把額度挪给別的站。
- 响應時間不稳定：时快时慢往往比稳定偏慢更麻烦，蜘蛛难以判断该给多少预算。
- 偶發慢：一般能容忍，但不要让它變成常態。
需要说清楚的是，慢並不等于被拉黑。多數情况下只是抓取變少、變浅，表現是入口頁被反复抓，内层頁面迟迟不被發現。
怎么测出接近真實的 TTFB
- 用同一台机器、同一时段多次請求，看中位數，而不是看最好的一次。
- 分別测静態頁和带查询參數的頁，很多慢是慢在動態參數上。
- 用不同地区的节点各测一次，蜘蛛来源不同，網絡路径差別很大。
- 對照訪問日誌里的抓取時間，確認服務器记錄和實测结果是否一致。
常见的几個瓶颈
- 後端逻辑過重：入口頁每次都要查库、調接口、渲染模板。
- 连接數打满：並發一高，新請求排队，TTFB 直接飙上去。
- 磁盘或缓存問题：日誌寫得太频繁、缓存命中率低。
- 網絡层：机房线路、回源配置、CDN 回源慢。
優化的先後顺序
先做静態化，把入口頁變成纯静態文件或加一层頁面缓存，這一步的收益通常最大。再做连接與並發限制，给蜘蛛留出稳定的通道。最後才考虑扩容和換线路。
不要為了追求一個漂亮的 TTFB 數字，把頁面改成蜘蛛看不懂的结构。速度和可讀性要一起看。
超时與重试設定的建议
- 入口頁的後端超时控制在合理范围内，別让一個請求挂太久。
- 對来自蜘蛛的請求，尽快返回明确的狀態碼，不要让它一直空等。
- 不要用長時間的重试去掩盖後端本身的問题，那样只會让日誌更难判断。
什么时候该考虑換机器
如果静態化之後 TTFB 依舊長時間偏高，並且換时段、換节点测下来都差不多，多半是线路或机房的問题，這时候繼續在代碼里找原因收益不大。反過来，如果只是高峰期抖一下，先別急着迁移，观察日誌里蜘蛛的抓取频次有没有同步下降再决定。
把响應速度当成一項長期维護的指标：固定時間测一次，记下中位數，再和抓取日誌對照。資料攒够了，你就能判断慢到什么程度會真的影响抓取，而不是凭感觉折腾。