蜘蛛抓取一个页面，本质上是一次下载任务：建立连接、拿到响应头、下载正文、再去解析。页面越大，这次下载占用的时间与连接就越长。在抓取资源有限的前提下，体积会直接影响单位时间内能抓到多少 URL。
一次抓取里，时间都花在哪
抓取不是点一下就完成的事。蜘蛛要先和服务器握手，等待首字节返回，再按响应头里的长度把正文读完，最后交给解析环节。前三步都属于网络传输，正文越大，占用的时间窗口越久。对于同一台服务器，一个 30 KB 的详情页和一个 1.5 MB 的列表页，抓取成本不在一个量级上。
页面被撑大的常见原因
- 把整站数据、配置或完整列表一次性内联进 HTML；
- 脚本与样式没有压缩，甚至同一段代码重复内联多次；
- 用 base64 把图片、字体直接写进文档；
- DOM 节点数量过大，解析成本随之上升；
- 模板里留下大量注释、空标签与废弃结构。
这些做法的共同点是：把本该按需加载的内容，全部塞进了初始响应里。
压缩是最省力的第一步
服务器开启 gzip 或 brotli，对 HTML、CSS、JS 这类文本内容通常能带来明显收益，因为文本本身可压缩的空间比较大。这里有两个容易踩的坑：一是压缩只在浏览器侧生效、对爬虫请求不生效，常见于 CDN 规则配置不当；二是对图片、视频这类已经压缩过的资源再压缩，几乎没有收益，反而增加 CPU 开销。
体积变大之后的连锁反应
- 单个 URL 的抓取耗时变长，抓取队列前进变慢；
- 同样的并发数下，单位时间可抓的页面数下降；
- 接近超时阈值时，抓取可能中断或重试，白白消耗一次机会；
- 带宽被大页面占满，小页面的响应时间也跟着变差。
注意最后一条：体积问题往往不是只影响那几个大页面，而是通过占用服务器与网络资源，间接拖慢整站的抓取体验。
可以动手调整的地方
- 列表页只输出必要的摘要字段，完整数据走接口或详情页；
- 非首屏内容延迟加载，但确保核心内容出现在初始 HTML 中；
- 合并并压缩静态资源，给它们设置较长的缓存策略；
- 图片使用外链并声明尺寸，避免内联进文档；
- 超长列表做分页或分段，让每一页的体积可控。
怎么确认有没有问题
从服务器日志里抽一段时间，统计每个响应的传输大小与响应时间，按体积排序看前几十个 URL。如果它们恰好是重要的列表页、分类页或详情页，就值得优先处理；如果只是少数导出页、打印页，优先级可以放低。也可以顺便看看这些 URL 的平均响应时间是否明显高于站点均值。
瘦身的目的不是迎合蜘蛛，而是让同样的抓取资源覆盖更多 URL。先看日志里的真实分布再决定动哪一块，不要为了减少几 KB 牺牲页面可用性。
还需要补充的是，体积只是抓取效率的一部分。服务器响应是否稳定、连接是否会被中途断开、内链是否把这些页面串联起来，同样决定蜘蛛能不能把 URL 抓完。把带宽、稳定性与内链放在一起看，比单独盯着 HTML 大小更接近实际情况。