入口頁能被抓，不代表蜘蛛愿意抓完。同样一批 URL，响應快的那组往往被抓得更深、更频繁；响應慢的那组，蜘蛛可能發几個請求就撤了。這一层的調優通常不需要改内容，只需要盯住几個服務器指标。
先分清三個時間
讨论快慢之前，先把耗时拆開，否則很容易誤判：
- 網絡往返：蜘蛛机房到服務器之間的物理延迟，主要由线路和地理位置决定，跨境线路差异尤其明顯。
- 服務端處理時間：程序执行、資料库查询、模板渲染加起来的時間，這是你能改的部分。
- 传輸時間：HTML 体积除以可用带宽，頁面越大、带宽越挤，這段越長。
三個數加起来才是蜘蛛感知到的等待。很多人只盯程序耗时，结果頁面里塞了大量内联脚本和外鏈资源，蜘蛛依然等得久。
TTFB 大概什么水平算正常
不给绝對值，给一個可操作的判断方法：把入口頁的 TTFB 和自己的一張纯静態頁做對比。
- 接近静態頁：說明動態開销已经压住，這個狀態可以接受。
- 明顯高于静態頁，但仍在几百毫秒量級：常见情况，通常還能用，重点看波動幅度。
- 经常超過一秒，或者忽快忽慢：值得排查，此时抓取深度和频次往往會下滑。
比平均值更值得關注的是尾延迟。10% 的請求要等三五秒，比全部請求稳定在五百毫秒更糟，因為蜘蛛的調度對超时相当敏感，一次超时可能就让整個抓取計划提前結束。
超时阈值：服務器、中間层、蜘蛛三處要對齐
一個請求可能被三處超时掐断：
- Web 服務器的连接保持與請求讀取超时，例如 Nginx 的 client 系列參數；
- 後端應用或資料库的连接與执行超时；
- 蜘蛛自身的抓取超时。
常见問题是只調了其中一层。比如 Nginx 给 60 秒，應用預設 30 秒，資料库 10 秒，蜘蛛最终拿到的往往是一個 500，而不是完整頁面。建议從外到内逐层收窄：外层最長，内层略短，让内层先失敗並返回明确狀態，而不是让外层硬等。
別让蜘蛛撞上静默等待
比超时更麻烦的是连接已建立、却迟迟不返回任何字节。蜘蛛在這種狀態下通常不會無限等，反复遇到之後可能降低對该站点的抓取频次。如果後端确實慢，宁可快速返回 503 並带上重试提示，也不要挂着不動。
並發與限速：入口頁不只有蜘蛛在訪問
入口頁往往同时承受蜘蛛抓取、监控探测和少量真實訪客。如果服務器不做区分，一次蜘蛛的並發抓取就可能把工作進程占满，後續請求全部排队，尾延迟随之飙升。可考虑的做法：
- 给入口頁加短时缓存，让绝大多數請求不落到動態程序上；
- 按 UA 或 IP 段给蜘蛛單獨限速，而不是全局一刀切；
- 把入口頁與後台接口分层部署，避免互相抢占连接數；
- 观察工作進程占用與队列長度，而不是只看 CPU 使用率。
排查清單
- 用同一台境外机器分別测入口頁和一張纯静態图，對比 TTFB；
- 看日誌里的响應時間分布，統計超過一秒的請求占比；
- 检查是否存在外层超时大于内层超时的情况；
- 確認 HTML 体积，尤其首屏之外是否有大段無用代碼；
- 確認蜘蛛請求是否與普通訪客共用同一套限速規則；
- 對比調整前後的蜘蛛抓取請求數，用資料判断是否真的改善。
响應速度不是玄学，它是一條能被日誌量化的曲线。多數时候，把尾延迟压下来，比把平均值再降五十毫秒更有價值。
小结
入口頁的响應速度属于基础设施层面的問题，改起来见效相對直接：拆清耗时来源、收紧内层超时、给蜘蛛單獨限速、盯住尾延迟。做完這几件事，再回头看抓取深度和频次的變化，才谈得上判断有没有起作用。