谈抓取预算时，多数人只看“条数”：蜘蛛今天来了几趟、抓走多少个 URL。但在一趟抓取里被消耗掉的资源，除了请求次数，还有传输的字节数和连接占用的时间。一个 3MB 的 HTML 页面和一个 30KB 的页面，在蜘蛛那边占用的抓取资源完全不是一个量级。
抓取成本其实有两个维度
把抓取想象成一条有带宽上限的管道会更容易理解：
- 请求次数：一段时间内蜘蛛愿意发出的请求数量，通常和站点整体质量、响应速度有关。
- 传输字节：每个响应体的大小。字节数越大，同样时间内能读完的 URL 越少。
- 连接时长：从建立连接到读完响应的时间，包含服务器处理与传输耗时，慢响应会占住并发位。
三者相互挤占。页面越大、响应越慢，单位时间里能走完的抓取路径就越短，一些本可以被发现的 URL 会被排到更后面。
页面体积是被什么撑大的
- 把图片、字体以内联 base64 的方式塞进 HTML。
- 首屏不需要的脚本、样式全部内联，模板重复代码多。
- 把整份接口数据以 JSON 形式嵌在页面里，其中大部分字段前端并不使用。
- 没有开启 gzip 或 brotli 压缩，文本资源按原样传输。
- 列表页一次性输出几百条条目，评论、问答默认展开全部内容。
这些做法单看每一项都不致命，叠加起来就很容易把一个本该几十 KB 的页面推到几 MB。
体积变大之后，抓取路径上的变化
- 同一个抓取窗口内完成的 URL 数量下降，深层页面被发现的周期变长。
- 传输时间拉长，超时和中断概率上升；一旦连接中断，页面后半部分的链接就来不及被读到。
- 列表页、分页页因为单页太重，翻页序列更容易停在前面几页。
- 站点出口带宽被单次抓取占用更多，正常用户的访问也可能受影响。
链接放的位置，决定它会不会被读到
HTML 是从上往下解析的。重要栏目、新增内容的入口链接放在靠前的位置，即便一次抓取中途被打断，这部分线索也已经被记录。反过来，把核心导航压在一层层模板和一堆内联脚本之后，读到的概率就低一些。这和站点整体内链结构是同一件事：把有限的抓取资源，优先引向真正需要被发现的页面。
服务器侧可以配合的几件事
- 开启 gzip 或 brotli 压缩，文本类资源通常能压到原来的两到三成。
- 确认首字节时间稳定，静态资源走缓存或 CDN，避免动态生成拖慢响应。
- 首屏之外的内容改为按需加载，但保留真实的链接与地址，不要用占位符替换。
- 列表页做分页或分批加载，每页条目控制在合理范围。
一个可执行的调整顺序
- 先从服务器日志里按响应字节数和响应时间排序，找出最重的那些 URL。
- 检查这些页面的压缩是否生效，这一步成本最低、见效最直接。
- 再动模板：内联数据、重复结构、无用脚本，能拆就拆。
- 最后调整链接布局与分页策略，把重要入口前移。
页面体积不是越小越好，而是要让每一 KB 都花在蜘蛛需要读到的东西上：可抓取的链接、正文内容、必要的结构化信息。首屏塞满装饰性资源，代价就是抓取节奏被拖慢。
这些调整不会立刻改变抓取结果，也不保证任何 URL 一定被收录，但它们减少的是实实在在的传输与时间成本。当抓取通道变宽，蜘蛛在同样的时间里能走完的路径自然更多，新 URL 被发现的等待窗口也会更短。