做蜘蛛池的人习惯把精力放在链接数量、入口布局和域名资源上，却常常忽略一个更基础的问题：入口页本身有多“重”。搜索蜘蛛抓一个页面，要先下载、再解析、再决定是否继续跟进页面里的链接。页面越臃肿，单次抓取占用的时间和带宽越多，同一时间段内能覆盖到的 URL 就越少。把入口页做轻，本质上是在给蜘蛛省成本。
体积从哪几个环节影响抓取
页面大小不会直接决定是否被抓，但它会参与蜘蛛对“这个站值不值得多来”的判断。影响大致集中在三个环节：
- 下载阶段：HTML 文档越大，单次请求耗时越长，达到超时阈值后被中断的概率越高。
- 解析阶段：节点越多，构建 DOM 的时间越长，链接提取也越慢，尤其是嵌套很深的结构。
- 配额阶段：同一个站点在单位时间内的抓取次数通常是有限的，重页面会挤占轻页面的机会。
这三个环节是叠加的。一个 500KB、节点上万、还要加载七八个脚本的入口页，实际消耗的资源可能是同内容精简页的好几倍。
多大的页面算“偏大”
没有硬性标准，但可以给自己设一条参考线，用来判断哪些入口页需要回头收拾：
- HTML 文档本身（未压缩前）尽量控制在 100KB 以内，压缩后通常能到 20KB 上下。
- DOM 节点数控制在 1500 以内比较从容，超过 3000 就值得检查结构。
- 首字节时间（TTFB）保持在一个稳定的较低区间，避免因后端查询过重而拖慢整站。
- 入口页里没有必须执行才能看到内容的阻塞脚本。
这些都是经验区间，不是及格线。真正要看的趋势是：同一个入口页改动前后，日志里它的抓取频次和回访间隔有没有变化。
DOM 复杂度的隐形膨胀
体积问题往往不是内容多，而是结构冗余。常见来源包括：
- 模板层层套娃，一个卡片外面裹了五六层 div。
- 大量内联样式和重复的 class 名，让 HTML 迅速变大。
- 同一份导航、页脚、侧栏在每个入口页里完整重复一遍。
- 统计、客服、埋点脚本在运行时注入额外节点，蜘蛛看到的和你在浏览器里看到的并非一回事。
- 为了视觉效果加的空容器和占位元素。
精简入口页的几个实用做法
- 开启 Gzip 或 Brotli 压缩，这是收益最大、改动最小的一步。
- 把公共导航和页脚做成结构简单的重复块，别为每个入口页单独定制一套 DOM。
- 能用 CSS 表达的效果不要写进 HTML，减少内联样式。
- 统计和埋点脚本尽量异步加载，避免阻塞正文解析。
- 列表页控制单页条数，宁可用分页也不要一次渲染几百条。
- 入口页的正文和链接直出在 HTML 里，不要依赖前端二次请求才能出现。
两种容易走偏的反向操作
一种是为了瘦身删内链。入口页的价值很大一部分来自链接，节点精简和链接数量要分开看，删掉该有的入口得不偿失。另一种是用脚本延迟渲染正文，看起来源码变干净了，但蜘蛛拿到的初始 HTML 里可能什么都没有，反而更糟。
体积优化的目标是让蜘蛛用更少的成本看到同样的内容，不是让源码看起来更短。判断标准始终是抓取日志，而不是文件大小本身。
怎么自查
不需要复杂工具，日常巡检可以固定看几项：查看压缩前后的 HTML 大小、统计 DOM 节点数量、观察 TTFB 波动、对比同批入口页之间的差异。如果某一批入口页的回访间隔明显长于其他批次，先去看它们的体积和结构，往往能找到原因。体积和 DOM 复杂度不是决定性因素，但它是一个可以主动控制、且改动成本很低的变量，值得放进日常维护清单里。