做蜘蛛池的人大多把精力花在 URL 數量、模板差异和連結位置上，因為這些看得见、改得快。但蜘蛛在看到一個入口頁之前，先要完成一次 HTTP 請求，而這次請求的快慢，會直接影响它愿不愿意繼續往下爬。入口頁响應慢，前面的准备工作做得再细，效果也會被拖住。
入口頁的响應速度由什么决定
一次請求從 DNS 解析開始，之後是 TCP 握手、TLS 协商，再到服務器處理並返回第一個字节。行业内通常把服務器返回第一個字节的時間叫 TTFB（Time To First Byte）。TTFB 之後才是 HTML 下载，以及 CSS、JS 等资源的請求。對搜尋蜘蛛来说，它更關心前面這几步，因為不完成完整渲染也能拿到連結和正文。
TTFB 偏高时會發生什么
响應時間變長，不是"慢一点"這么简單，它會在几個地方同时产生影响：
- 請求在超时時間内没有返回，抓取程序直接放弃，這次记錄就是失敗；
- 單次抓取耗时變長，同样的抓取预算能覆盖的 URL 數量變少；
- 同一台服務器上的入口頁互相抢资源，慢的會拖累快的；
- 部分抓取程序會整体降低對相關站点的訪問频率，回訪間隔被拉長。
入口頁常见的几個拖慢原因
- 入口頁靠資料库實时生成：每次訪問都查一次库，URL 一多就開始排队；
- 入口頁集中在一台机器：多個域名共用一個進程或一個连接池，慢請求互相拖累；
- 同步調用外部接口：頁面里嵌了統計、翻译或素材接口，接口一慢整頁就卡住；
- 日誌同步寫入：訪問日誌直接寫本地磁盘或寫遠程库，並發一高就成為瓶颈；
- 缓存策略缺位：入口頁内容其實是固定的，却被当成動態頁每次都重新生成。
怎么测：几個能落地的動作
- 用 curl 或浏览器的網絡面板看單次請求的 TTFB，而不是只看頁面整体加载時間；
- 換不同的出口 IP 和地区测，先排除自己本地網絡的影响；
- 在訪問日誌里按小时統計平均响應時間和超时比例，看趋势而不是看某一次；
- 把不同入口頁的時間分布拉出来對比，找出明顯偏慢的那一批。
優化方向與邊界
入口頁本身不需要复杂功能，能稳定返回一批可用連結就够了。把列表資料提前生成静態文件、把日誌改成异步寫入、把多個域名分散到不同進程或机器，都是成本不高的改法。如果上了 CDN，注意入口頁的缓存規則，哪怕只缓存几十秒，也比每次回源要好。
但没必要把 TTFB 压到极致。入口頁只是通道，蜘蛛對响應時間只有一個比較模糊的容忍区間，几百毫秒和一百毫秒的差別，通常不會体現在抓取行為上。真正值得花時間的是別让頁面動不動就超时。
响應速度的底线是"稳定在超时线以内"，而不是"跑得多快"。偶發的慢請求比整体偏慢更麻烦，因為它會让抓取结果變得很难判断。
和其他环节的配合
响應速度和抓取节奏是绑在一起的。如果入口頁每秒只能扛住十来個請求，却按每秒五十個去喂，结果就是大量超时，日誌里看起来像池子没在干活，實际上是服務器被自己压垮了。限速、缓存和服務器規格之間需要大致對齐，具体數值可以從實际日誌里反推。
另外，响應時間最好和其他指标一起看。只看抓取總量，容易把"蜘蛛来得少"和"来了但没抓完"混為一谈；把超时比例、平均响應時間和成功抓取的 URL 數放在一起看，判断會清楚很多。