谈抓取预算时，多數人只看“條數”：蜘蛛今天来了几趟、抓走多少個 URL。但在一趟抓取里被消耗掉的资源，除了請求次數，還有传輸的字节數和连接占用的時間。一個 3MB 的 HTML 頁面和一個 30KB 的頁面，在蜘蛛那邊占用的抓取资源完全不是一個量級。
抓取成本其實有两個维度
把抓取想象成一條有带宽上限的管道會更容易理解：
- 請求次數：一段時間内蜘蛛愿意發出的請求數量，通常和站点整体质量、响應速度有關。
- 传輸字节：每個响應体的大小。字节數越大，同样時間内能讀完的 URL 越少。
- 连接时長：從建立连接到讀完响應的時間，包含服務器處理與传輸耗时，慢响應會占住並發位。
三者相互挤占。頁面越大、响應越慢，單位時間里能走完的抓取路径就越短，一些本可以被發現的 URL 會被排到更後面。
頁面体积是被什么撑大的
- 把图片、字体以内联 base64 的方式塞進 HTML。
- 首屏不需要的脚本、样式全部内联，模板重复代碼多。
- 把整份接口資料以 JSON 形式嵌在頁面里，其中大部分字段前端並不使用。
- 没有開啟 gzip 或 brotli 压缩，文本资源按原样传輸。
- 列表頁一次性輸出几百條條目，评论、問答預設展開全部内容。
這些做法單看每一項都不致命，叠加起来就很容易把一個本该几十 KB 的頁面推到几 MB。
体积變大之後，抓取路径上的變化
- 同一個抓取窗口内完成的 URL 數量下降，深层頁面被發現的周期變長。
- 传輸時間拉長，超时和中断概率上升；一旦连接中断，頁面後半部分的連結就来不及被讀到。
- 列表頁、分頁頁因為單頁太重，翻頁序列更容易停在前面几頁。
- 站点出口带宽被單次抓取占用更多，正常用戶的訪問也可能受影响。
連結放的位置，决定它會不會被讀到
HTML 是從上往下解析的。重要栏目、新增内容的入口連結放在靠前的位置，即便一次抓取中途被打断，這部分线索也已经被记錄。反過来，把核心導航压在一层层模板和一堆内联脚本之後，讀到的概率就低一些。這和站点整体内鏈结构是同一件事：把有限的抓取资源，優先引向真正需要被發現的頁面。
服務器侧可以配合的几件事
- 開啟 gzip 或 brotli 压缩，文本類资源通常能压到原来的两到三成。
- 確認首字节時間稳定，静態资源走缓存或 CDN，避免動態生成拖慢响應。
- 首屏之外的内容改為按需加载，但保留真實的連結與地址，不要用占位符替換。
- 列表頁做分頁或分批加载，每頁條目控制在合理范围。
一個可执行的調整顺序
- 先從服務器日誌里按响應字节數和响應時間排序，找出最重的那些 URL。
- 检查這些頁面的压缩是否生效，這一步成本最低、见效最直接。
- 再動模板：内联資料、重复结构、無用脚本，能拆就拆。
- 最後調整連結布局與分頁策略，把重要入口前移。
頁面体积不是越小越好，而是要让每一 KB 都花在蜘蛛需要讀到的東西上：可抓取的連結、正文内容、必要的结构化信息。首屏塞满装饰性资源，代價就是抓取节奏被拖慢。
這些調整不會立刻改變抓取结果，也不保證任何 URL 一定被收錄，但它們减少的是實實在在的传輸與時間成本。当抓取通道變宽，蜘蛛在同样的時間里能走完的路径自然更多，新 URL 被發現的等待窗口也會更短。