聊抓取效率时，很多人先看 URL 数量、抓取频次、Sitemap 提交量，却忽略了一个更基础的变量：每个 URL 返回的响应体有多大。蜘蛛一次抓取，不只要建立连接、等待响应，还要把 HTML 读进来、解析出链接和正文。页面越重，单次抓取占用的时间和带宽越多，留给其他 URL 的机会自然会被压缩。
一次抓取，蜘蛛实际要处理什么
从蜘蛛的视角看，一次抓取大致包括：请求 URL、等待首字节、接收响应体、解析 HTML、提取可跟进链接。抓取预算经常被理解为“能发多少个请求”，但在实际调度里，响应时间、响应体大小、解析失败率都会影响下一次请求什么时候发出。一个 2MB 的 HTML 和一个 20KB 的 HTML，即使 URL 数量相同，对抓取通道的占用也完全不同。
页面变“重”的常见原因
- 把大量结构化数据直接内联在 HTML 里，例如首屏就塞进几千条商品或文章记录。
- 列表页一次性输出过多条目，分页形同虚设。
- 把 CSS、JavaScript 甚至 Base64 图片全部内联，导致 HTML 体积成倍增长。
- 服务端把评论、历史版本、隐藏 Tab 的内容全部渲染进同一个页面。
- 没有开启压缩，或者压缩只对静态资源生效，HTML 仍是原始大小传输。
体积过大时，抓取侧可能出现哪些变化
需要说明的是，蜘蛛不会因为页面大就“一定不抓”或“一定不收录”，但体积过大会带来一些现实影响。首先是接收和解析耗时增加，遇到超时设置较紧的抓取队列，可能只读到部分响应就结束。其次是解析成本上升，DOM 节点过多时，提取链接和正文的效率下降。再次是同一时间段内能完成的请求数减少，抓取节奏变慢。对于新站或抓取频率本来就不高的站点，这种变化会更明显。
体积问题很少单独出现，它往往和服务器响应慢、DOM 复杂、内链混乱一起发生。排查时不要只盯 HTML 大小一个数字。
怎么判断自己的页面是不是太重
- 查看 HTML 原始体积和压缩后体积，分别记录。压缩后仍然偏大，才更值得处理。
- 观察首字节时间。如果服务器本身响应慢，再小的页面也会拖累抓取。
- 统计 DOM 节点数量和主要容器的嵌套深度，节点过多会增加解析成本。
- 检查内联脚本、内联样式和 Base64 资源占了多少体积。
- 用抓取日志对照：蜘蛛是否经常只抓到一半、是否频繁超时、是否很少继续深入。
做轻量化的几个方向
- 列表分页：每页保留合理条数，让蜘蛛通过翻页逐步发现内容，而不是一次吃下全部。
- 延迟加载但保留链接：图片可以懒加载，但指向详情页的 a 标签尽量在初始 HTML 里可解析。
- 数据异步化：把非首屏、非 SEO 必需的数据放到接口请求里，减少初始 HTML 体积。
- 开启压缩与缓存：对 HTML 启用 gzip 或 brotli，配合合理的缓存策略，降低重复抓取的传输成本。
- 控制内联资源：必要的首屏样式可以内联，但不要把整个 CSS/JS 包塞进每个页面。
轻量页面如何配合内链和 Sitemap
蜘蛛发现 URL 的路径通常来自 Sitemap、内链和外链。Sitemap 负责给出候选清单，内链负责让蜘蛛在站内继续走。如果页面 HTML 很重，解析出的链接可能不完整，内链的传导效果就会打折扣。反过来，页面结构清晰、链接位置靠前、响应体可控，蜘蛛在相同抓取次数里能走到的 URL 会更多。Sitemap 里的 URL 最好也能在站内找到对应入口，避免只靠提交、没有内链支撑。
一个更实际的判断顺序
遇到抓取量上不去时，可以先排除服务器稳定性和状态码问题，再看页面体积和解析成本。如果同一批 URL 中，小页面抓取正常、大页面明显偏慢或容易中断，那体积就是需要处理的变量。调整后观察抓取日志里的响应体接收情况和后续 URL 的抓取数量，不要只看某一天的抓取总量。
把页面做轻，不等于牺牲内容，而是让蜘蛛用更低的成本拿到该发现的东西。对于依赖持续抓取的站点来说，这往往比单纯增加提交量更值得先做。