聊抓取预算时，很多人的注意力都在“一天抓了多少次”上。但對搜尋引擎来说，抓取容量通常按主机维度分配，衡量指标里既有請求數，也有传輸字节和並發连接數。換句话说，一個 300KB 的 HTML 和一個 30KB 的 HTML，占用的抓取资源並不一样。在同样的時間窗口里，從重頁面上能走過的 URL 更少。
抓取容量里，字节數也算一份
搜尋引擎爬虫一般會為每個站点设定並發连接和带宽上限，避免抓取影响到服務器對外服務。這個上限是共享的：如果每個頁面返回的响應体都很大，單位時間内能完成的請求數就會下降；如果响應体很小，蜘蛛可以用同样的容量走更多地址。
所以有时候出現的情况是：服務器响應很快，狀態碼也正常，但抓取量就是上不去。原因不在速度，而在每個頁面“拖”走的字节太多。
HTML 里哪些重量是白費的
- 整站導航和頁脚在每個頁面里重复内联，且带有大量样式属性，本身不提供新的連結價值，却反复出現。
- 把首屏不需要的資料以 JSON 形式塞進頁面，尤其是列表頁把全量資料一次性渲染。
- 把图片以 base64 直接寫進 HTML，看起来少了一次請求，實际把整個文件變成了 HTML 的一部分。
- 大段注释、未清理的空行和缩進、模板遗留的調试信息。
- 一個列表頁直接輸出上千條連結，其中大部分是蜘蛛目前不需要走的分頁和篩選入口。
這些内容對用戶可能有用，但對蜘蛛来说，每多一個字节，都是抓取队列里的一次消耗。
压缩與传輸：同一份 HTML，体积能差几倍
開啟 gzip 或 brotli 之後，文本型 HTML 的体积通常能压缩到原来的两到三成。未開啟压缩时，HTML 會以接近原始大小传輸，抓取效率直接受影响。
還要注意压缩是否對各類爬虫一致。有些站点在 CDN 或反向代理层做了基于 User-Agent 的分流，導致蜘蛛拿到的响應没有压缩，而普通浏览器訪問时是压缩過的。排查时可以對比两者返回的 Content-Encoding 响應头。
渲染抓取會額外拉取资源
当蜘蛛需要执行頁面脚本来获取内容时，它會顺带請求 CSS、JS、字体和部分图片。這些资源不一定都計入抓取预算，但會占用渲染队列的時間和带宽。如果每個頁面都要加载几百 KB 的脚本，渲染一次的成本會明顯高于纯 HTML 頁面。
對内容頁来说，把正文直接輸出在 HTML 里，比依赖脚本注入更省资源，也更稳定。
怎么查自己的頁面是不是“重”
- 抽样几個模板頁，比較未压缩 HTML 大小與压缩後的大小，看比值是否合理。
- 查看服務器日誌中蜘蛛請求的响應字节數，如果日誌有记錄的话，按模板類型排序。
- 分別統計詳情頁、列表頁、标簽頁的平均体积，找出最重的那一類。
- 检查是否每個頁面都内联了同一份大块資料或同一套样式。
- 用關閉 JS 的方式看首屏，確認關键連結和正文是否已经在 HTML 中。
優化时的取舍
减小体积不等于删掉功能。目标是把蜘蛛真正需要的東西留下，把與抓取無關的重量挪走：能外部化的脚本和样式就外部化，能按需加载的資料就不要首屏全量輸出，能压缩的响應就统一開啟压缩。
抓取效率是算總帳的。頁面轻一点，蜘蛛在同样的時間里就能多走几步；這几步累加起来，往往比一次集中提交更管用。