蜘蛛抓取一个页面，本质上就是一次 HTTP 请求。服务器返回的响应体越大，这次请求占用的时间、连接和带宽就越多。抓取并不是无限资源，同一台服务器在单位时间里能被抓走的页面数是有上限的，页面越重，能走过的页面就越少。
页面体积通常从哪来
常见的几个源头：
- 没有开启压缩，HTML 原样传输，体积可能是压缩后的三到五倍；
- 把图片转成 base64 内嵌在 HTML 或 CSS 里，一张图就可能几十上百 KB；
- 把整段结构化数据塞进 script 标签，首屏根本用不到；
- 列表页一次输出几百条记录，还带上缩略图和摘要；
- 模板遗留的大量注释、重复的样式与脚本。
这些内容未必对用户有用，但对蜘蛛来说，抓一次就要多付一次成本。真正的问题不是“页面大”，而是“大得没有必要”。
响应体积和抓取节奏的关系
爬虫在安排抓取时，会同时考虑服务器的承受能力。一个响应要传输十秒，和传输零点几秒，对同一站点后续的抓取节奏影响完全不同。体积大往往还伴随解析慢、渲染成本高，内联脚本多的页面尤其明显。
更隐蔽的是重定向链。一次跳转就是一次额外的请求，如果链条有三四跳，最后落到的那页又很大，蜘蛛为这一个 URL 付出的成本会成倍上升。
压缩是最省事的一步
服务器开启 gzip 或 brotli 之后，HTML、CSS、JS、JSON 的体积通常能降到原来的三成左右。注意两点：
- 确认响应头里的 Content-Encoding 正确，蜘蛛和浏览器才能正常解码；
- 不要再去压缩已经压过的文件，比如图片、视频，收益很小还可能出错。
压缩减少的是传输体积，不改变页面内容，属于低风险、见效较快的调整。
列表页和分页要克制
列表页是蜘蛛走进内容页的主要通道。如果一页塞进几百条链接，响应体庞大、链接密度过高，蜘蛛在这页上花的时间变多，向下一层推进的速度反而变慢。把每页条数控制在合理范围，配合清晰的分页链接，通常比“一页装完”更好走。
怎么确认是不是体积问题
- 查看服务器日志里的响应字节数，找出排在前面的“大页面”；
- 用浏览器开发者工具或测速工具看传输大小与传输时间；
- 对比压缩前后的字节数，确认压缩真的生效；
- 检查重定向链，把多跳合并成一跳。
不要为了省体积牺牲内容
体积优化的目标是去掉冗余，而不是删掉用户需要的信息。图片该保留的还是要保留，只是换成合理尺寸并做好压缩；重复的内联脚本可以抽成外部文件并压缩传输。正文内容不该为了变小而被折叠隐藏，那样省下的流量，换来的往往是更差的体验。