蜘蛛在單位時間里能抓多少頁面，取决于两件事：它愿意给這個站多少抓取配額，以及每次抓取本身要花多久。前者通常不好直接干预，後者却经常被忽略。同一個配額下，單次抓取耗时 200 毫秒的站点和耗时 2 秒的站点，能走完的 URL 數量差出一個量級。
抓取是排队推進，不是同时開闸
對單個站点，蜘蛛一般只维持有限的並發连接，其余請求在队列里等待。队列的推進速度由每個請求的完成時間决定。一個頁面拖得久，後面排队的頁面就都往後挪。URL 發現本质上是一個连續動作：先抓到列表頁，才能從中讀到詳情頁的連結。鏈條上任何一环變慢，後面的 URL 都要等。
單次抓取的時間花在哪几段
- DNS 解析、建立连接、TLS 握手：通常是固定開销，但连接复用差、證书鏈冗長时會明顯放大。
- 首字节時間（TTFB）：服務端處理、資料库查询、缓存命中率都体現在這一段。
- 传輸時間：與响應体大小直接相關，HTML 越大传得越久。
- 客戶端渲染：如果頁面依赖 JavaScript 才能出内容，還要額外排队等渲染资源。
很多人只盯 TTFB，但传輸時間在体积失控的站点里占比可能更高。一個 1.5MB 的 HTML，在同样的带宽條件下，光传輸就可能比正常頁面多出几百毫秒。
頁面体积的常见来源
体积不會無缘無故變大，通常来自這几處：
- 模板里重复輸出的内联样式和脚本，每個頁面都带一份。
- 把首屏資料序列化成 JSON 直接嵌進 HTML。
- CSS 或小图被轉成 Base64 内联，体积反而膨胀。
- 未压缩的 HTML，大量空白字符和格式化缩進。
- DOM 节点數過多，列表頁把几百條資料一次性铺满。
其中前两條最容易被忽视，因為它們在開發环境里看起来很方便，上线後却让每個頁面都重了几百 KB。
体积大的頁面不只拖慢自己
抓取队列的连带效應
当一個頁面占用的時間變長，同一批次里其他 URL 的抓取間隔也被拉長。表現上就是：老頁面還在被反复抓，新上线的 URL 迟迟没有第一次訪問记錄。翻抓取日誌时，這類問题往往不是"某個頁面抓得慢"，而是整段時間里抓取次數整体偏低。
列表頁尤其關键
詳情頁被抓一次就够，列表頁却是 URL 發現的枢纽，被抓频次高得多。列表頁体积每增加一点，造成的總時間损耗會被放大很多倍。
可以動手調整的几處
- 開啟 gzip 或 brotli 压缩，先確認 HTML 是否真的在压缩传輸。
- 清理模板中重复的内联样式與脚本，能外鏈的別内联。
- Base64 内联只用在极小的图标上，其余保持獨立资源。
- 控制列表頁的預設條數，把超長列表交给服務端分頁。
- 给静態和半静態頁面加缓存，让 TTFB 保持稳定而不是忽高忽低。
- 检查是否把整站導航全量塞進每個頁面，尤其是层級很深的站。
怎么判断是体积在拖後腿
- 看抓取統計里的平均响應時間與平均下载大小，两個指标一起看。
- 在服務器日誌里按目錄分组，比較同類頁面的抓取間隔。
- 對比不同 UA 下的响應時間，確認是否有一條鏈路特別慢。
- 抽查体积最大的那几十個 URL，看它們是不是被抓得特別频繁。
別只测首頁。首頁往往是全站優化最好的頁面，列表頁和詳情頁的响應分布才更能說明問题。
把單次抓取的耗时压下来，等于在同样的抓取配額里腾出更多位置，留给那些還没被發現的 URL。這件事不需要一次做完，可以先從体积最大、被抓最频繁的那几類頁面入手，观察一段時間日誌再做下一轮。