入口頁铺得再多，蜘蛛每次来只做一件事：發請求、等响應、决定要不要繼續。响應慢，它不會投诉，只會降低来訪频率，把抓取预算挪到別的站点。所以响應速度不是一個“性能問题”，而是入口頁能不能被持續抓取的前置條件。

蜘蛛的等待是有上限的

搜尋引擎爬虫對單次請求的等待時間通常有几秒到十几秒的超时阈值，各家數值不同，也不會對外公開。你不需要记住精确數字，只要理解一件事：当服務器响應超過這個阈值，這次抓取就算失敗。失敗次數累积到一定程度，調度端會認為這個站点不稳定，把抓取配額往下压。

這個過程是渐進的，不會一次性给你惩罚。所以很多人是在日誌里看到蜘蛛請求數慢慢變少，才回头去找原因。

TTFB 比“頁面打開速度”更關键

不少人看的是頁面完全加载時間，但蜘蛛判断快慢的主要依據是首字节時間，也就是從發出請求到收到第一段响應的時間。图片、CSS、JS 這些资源一般不影响它對入口頁 HTML 的判断。

• TTFB 在几百毫秒内：基本不會成為問题
• 1～2 秒：偶尔可以，長期如此容易被降频
• 超過 3 秒：失敗率上升，多线程抓取时更明顯

需要說明的是，這些只是经驗区間，不是官方标准。不同爬虫、不同时段、不同机房线路，表現都會有差异，最终還是要以自己站点日誌為准。

哪些“慢”是假慢

很多入口頁本身是静態的，却依然很慢，問题往往出在鏈路而不是内容：

1. DNS 解析慢：解析服務不稳定，或者 CNAME 层級堆得太多
2. TLS 握手慢：證书鏈不完整、不支持會话复用、强制跳轉层數過多
3. 回源慢：CDN 缓存命中率低，每来一個請求都回源到後端
4. 後端慢：入口頁動態生成时查库、調接口、等外部服務
5. 出口拥塞：同一台机器上站点過多，带宽被其他业務占满

排查时建议先用命令行工具分別测 DNS、建连、TLS、首字节這几段，定位到具体环节再改，不要一上来就動代碼。

比“慢”更麻烦的是错誤响應

超时只是让蜘蛛等，5xx 和 429 會让它直接判定失敗。入口頁里如果有一批 URL 長期返回 500、502、503，或者因為限流频繁返回 429，影响會扩散到同一域名下的其他頁面。

• 出現 5xx 先查應用日誌，確認是偶發還是持續
• 429 要谨慎使用，蜘蛛被限流後不會立刻恢复到原来的频率
• 连接被重置、半開连接，表現和超时接近，但更难被發現

几項可以實际動手的調整

不需要做很复杂的事，先把最影响响應時間的环节處理掉：

• 入口頁尽量静態化或加一层缓存，避免每次請求都走動態渲染
• 把入口頁和重业務站点分開部署，避免互相抢 CPU 和连接數
• 给蜘蛛来源留出單獨的连接數和带宽，但不要用极端規則直接拦截
• 监控按狀態碼分组的响應時間，而不是只看整体平均值

別把速度優化做成另一场军备竞赛

响應速度是基础條件，不是效果保證。入口頁能在合理時間内返回正常内容，蜘蛛愿意持續来訪，這就够了。如果把精力全投在毫秒級優化上，却忽视頁面质量、連結關系和重复度，收益通常不成比例。

判断标准其實很简單：看日誌里蜘蛛請求的成功率和频率趋势，而不是看某個体檢測试工具的分數。分數好看但蜘蛛不来，說明真正的問题不在速度上。