很多人搭建蜘蛛池入口页时，只要页面能打开、链接能跳转就算完成，很少关注页面体积。实际上，入口页承担的是“被发现”和“被继续爬取”的任务，如果单个页面过大，抓取端下载和解析的成本就会上升，在同等抓取预算下能访问的 URL 数量可能减少。
页面体积为什么会拖慢抓取
搜索引擎蜘蛛抓取一个页面，大致要经历下载 HTML、解析 DOM、提取链接三个阶段。体积过大主要影响前两步：
- 下载耗时：同样的带宽下，几百 KB 的 HTML 比几十 KB 的慢不少，尤其是蜘蛛从境外或跨运营商访问时。
- 解析成本：DOM 节点越多、内联脚本越复杂，解析时间越长，部分抓取端会对超大页面做截断处理。
- 抓取预算：单页耗时增加，单位时间内完成的抓取量下降，链接被“看到”的机会自然变少。
这些影响不是绝对的，取决于抓取端的策略和服务器的实际响应情况，但体积是相对容易自己控制的变量之一。
入口页的体积参考线
- HTML 源码：常规入口页控制在 100KB 以内比较从容，超过 300KB 就值得检查有没有冗余。
- DOM 节点：1500 个以内通常解析较快，几千个节点的页面在移动端会明显吃力。
- 外部资源：CSS、JS、字体、图片加起来的请求数，建议控制在 15 个以内。
这些是经验值而非标准，不同类型的站点差异很大，重点是把它们当作自查的起点。
最容易被忽略的三类冗余
1. 模板自带的整站资源
很多入口页是从主站或某个模板复制过来的，带着整站导航、轮播图脚本、评论组件。这些内容入口页根本用不到，却会一并被下载和加载。
2. 全量引入的图标库与字体
为了几个图标引入一个几百 KB 的字体文件，或者加载完整图标集，是很常见的浪费。可以改成内联 SVG 或使用图标字体子集。
3. base64 图片与未压缩图片
把图片转成 base64 直接写进 HTML，会让 HTML 本身膨胀，并且无法被单独缓存。图片该压缩就压缩，该放到独立资源地址就独立放。
精简时不要丢掉的东西
- 指向目标页的链接和锚文本，这是入口页存在的意义。
- 一定量的正文文本，纯链接堆砌的页面可读性差。
- 能正常访问的状态码与相对稳定的响应。
一个可执行的精简顺序
- 先用浏览器开发者工具或命令行工具看 HTML 大小和请求数量，找出体积最大的几个文件。
- 删掉入口页用不到的整站脚本和样式，只保留页面实际渲染需要的部分。
- 压缩 HTML、CSS、JS，开启 gzip 或 brotli。
- 图片换格式、降尺寸，非首屏图片延迟加载。
- 改完后连续观察几天的抓取日志，对比抓取数量和到达目标页的比例。
体积精简的目标是让页面更“轻”，而不是做极限压缩。为了省下几百字节把维护性搞得很差，反而得不偿失。
常见误区
- 越轻越好：把内容砍到只剩一行链接，页面质量下降，可能得不偿失。
- 只看一个样本：入口页往往是模板批量生成的，要抽查多个页面而不是只看一个。
- 用前端渲染省流量：把正文改成异步加载并不会减少抓取端的工作量，反而增加不确定性。
- 压缩后不验证：压缩配置写错导致脚本报错、页面白屏，比体积大更麻烦。
最后，体积只是入口页可维护性的一部分。把体积、响应速度、状态码、链接结构放在一起看，定期做小批量抽查，比一次性大改更稳妥。