蜘蛛抓取一個頁面，本质上是一次下载任務：建立连接、拿到响應头、下载正文、再去解析。頁面越大，這次下载占用的時間與连接就越長。在抓取资源有限的前提下，体积會直接影响單位時間内能抓到多少 URL。
一次抓取里，時間都花在哪
抓取不是点一下就完成的事。蜘蛛要先和服務器握手，等待首字节返回，再按响應头里的長度把正文讀完，最後交给解析环节。前三步都属于網絡传輸，正文越大，占用的時間窗口越久。對于同一台服務器，一個 30 KB 的詳情頁和一個 1.5 MB 的列表頁，抓取成本不在一個量級上。
頁面被撑大的常见原因
- 把整站資料、配置或完整列表一次性内联進 HTML；
- 脚本與样式没有压缩，甚至同一段代碼重复内联多次；
- 用 base64 把图片、字体直接寫進文档；
- DOM 节点數量過大，解析成本随之上升；
- 模板里留下大量注释、空标簽與废弃结构。
這些做法的共同点是：把本该按需加载的内容，全部塞進了初始响應里。
压缩是最省力的第一步
服務器開啟 gzip 或 brotli，對 HTML、CSS、JS 這類文本内容通常能带来明顯收益，因為文本本身可压缩的空間比較大。這里有两個容易踩的坑：一是压缩只在浏览器侧生效、對爬虫請求不生效，常见于 CDN 規則配置不当；二是對图片、视频這類已经压缩過的资源再压缩，几乎没有收益，反而增加 CPU 開销。
体积變大之後的连鎖反應
- 單個 URL 的抓取耗时變長，抓取队列前進變慢；
- 同样的並發數下，單位時間可抓的頁面數下降；
- 接近超时阈值时，抓取可能中断或重试，白白消耗一次机會；
- 带宽被大頁面占满，小頁面的响應時間也跟着變差。
注意最後一條：体积問题往往不是只影响那几個大頁面，而是通過占用服務器與網絡资源，間接拖慢整站的抓取体驗。
可以動手調整的地方
- 列表頁只輸出必要的摘要字段，完整資料走接口或詳情頁；
- 非首屏内容延迟加载，但确保核心内容出現在初始 HTML 中；
- 合並並压缩静態资源，给它們設定較長的缓存策略；
- 图片使用外鏈並声明尺寸，避免内联進文档；
- 超長列表做分頁或分段，让每一頁的体积可控。
怎么確認有没有問题
從服務器日誌里抽一段時間，統計每個响應的传輸大小與响應時間，按体积排序看前几十個 URL。如果它們恰好是重要的列表頁、分類頁或詳情頁，就值得優先處理；如果只是少數導出頁、打印頁，優先級可以放低。也可以顺便看看這些 URL 的平均响應時間是否明顯高于站点均值。
瘦身的目的不是迎合蜘蛛，而是让同样的抓取资源覆盖更多 URL。先看日誌里的真實分布再决定動哪一块，不要為了减少几 KB 牺牲頁面可用性。
還需要补充的是，体积只是抓取效率的一部分。服務器响應是否稳定、连接是否會被中途断開、内鏈是否把這些頁面串联起来，同样决定蜘蛛能不能把 URL 抓完。把带宽、稳定性與内鏈放在一起看，比單獨盯着 HTML 大小更接近實际情况。