聊抓取预算时，很多人的注意力都在“一天抓了多少次”上。但对搜索引擎来说，抓取容量通常按主机维度分配，衡量指标里既有请求数，也有传输字节和并发连接数。换句话说，一个 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 中。
优化时的取舍
减小体积不等于删掉功能。目标是把蜘蛛真正需要的东西留下，把与抓取无关的重量挪走：能外部化的脚本和样式就外部化，能按需加载的数据就不要首屏全量输出，能压缩的响应就统一开启压缩。
抓取效率是算总账的。页面轻一点，蜘蛛在同样的时间里就能多走几步；这几步累加起来，往往比一次集中提交更管用。