蜘蛛抓取一個頁面，本质上就是一次 HTTP 請求。服務器返回的响應体越大，這次請求占用的時間、连接和带宽就越多。抓取並不是無限资源，同一台服務器在單位時間里能被抓走的頁面數是有上限的，頁面越重，能走過的頁面就越少。
頁面体积通常從哪来
常见的几個源头：
- 没有開啟压缩，HTML 原样传輸，体积可能是压缩後的三到五倍；
- 把图片轉成 base64 内嵌在 HTML 或 CSS 里，一張图就可能几十上百 KB；
- 把整段结构化資料塞進 script 标簽，首屏根本用不到；
- 列表頁一次輸出几百條记錄，還带上缩略图和摘要；
- 模板遗留的大量注释、重复的样式與脚本。
這些内容未必對用戶有用，但對蜘蛛来说，抓一次就要多付一次成本。真正的問题不是“頁面大”，而是“大得没有必要”。
响應体积和抓取节奏的關系
爬虫在安排抓取时，會同时考虑服務器的承受能力。一個响應要传輸十秒，和传輸零点几秒，對同一站点後續的抓取节奏影响完全不同。体积大往往還伴随解析慢、渲染成本高，内联脚本多的頁面尤其明顯。
更隐蔽的是重定向鏈。一次跳轉就是一次額外的請求，如果鏈條有三四跳，最後落到的那頁又很大，蜘蛛為這一個 URL 付出的成本會成倍上升。
压缩是最省事的一步
服務器開啟 gzip 或 brotli 之後，HTML、CSS、JS、JSON 的体积通常能降到原来的三成左右。注意两点：
- 確認响應头里的 Content-Encoding 正确，蜘蛛和浏览器才能正常解碼；
- 不要再去压缩已经压過的文件，比如图片、视频，收益很小還可能出错。
压缩减少的是传輸体积，不改變頁面内容，属于低風險、见效較快的調整。
列表頁和分頁要克制
列表頁是蜘蛛走進内容頁的主要通道。如果一頁塞進几百條連結，响應体庞大、連結密度過高，蜘蛛在這頁上花的時間變多，向下一层推進的速度反而變慢。把每頁條數控制在合理范围，配合清晰的分頁連結，通常比“一頁装完”更好走。
怎么確認是不是体积問题
- 查看服務器日誌里的响應字节數，找出排在前面的“大頁面”；
- 用浏览器開發者工具或测速工具看传輸大小與传輸時間；
- 對比压缩前後的字节數，確認压缩真的生效；
- 检查重定向鏈，把多跳合並成一跳。
不要為了省体积牺牲内容
体积優化的目标是去掉冗余，而不是删掉用戶需要的信息。图片该保留的還是要保留，只是換成合理尺寸並做好压缩；重复的内联脚本可以抽成外部文件並压缩传輸。正文内容不该為了變小而被折叠隐藏，那样省下的流量，換来的往往是更差的体驗。