蜘蛛抓取一个页面时，最先拿到的是服务器返回的 HTML 源码，而不是浏览器渲染完成之后的样子。这意味着页面体积和正文在源码里的位置，直接决定了这次抓取能拿到多少有效信息。
页面为什么会变胖
一个页面的 HTML 从几十 KB 涨到几百 KB，通常不是因为正文变长，而是因为几类容易被忽略的部分：
- 直接写在页面里的 CSS 与 JS，尤其是未压缩、未合并的版本；
- 只有前端脚本会用到的数据，被整个序列化进 script 标签；
- 大量重复的导航、页脚、推荐位、弹窗模板；
- 以 Base64 内联的图片、字体和图标。
这些内容对用户是必要的，对蜘蛛来说大多是噪声。它们不会让页面被判为无用，但会挤占每次抓取的传输与解析成本。
正文位置：越靠前越容易被稳定提取
蜘蛛通常按文档顺序读取源码。如果正文出现在几十 KB 的脚本和导航之后，抓取和解析都要多绕一步。更稳妥的做法是让主体内容尽早出现在 HTML 中：把主标题、正文、发布时间等关键信息放在靠前的位置，把脚本放到后面或改为异步加载。
这并不是要牺牲页面效果，而是调整源码里内容的先后顺序。同样的视觉效果，源码顺序不同，蜘蛛读到的“第一印象”也不同。
一次抓取的成本
抓取是有限资源。页面越大，一次抓取占用的连接时间越长；在抓取频次基本稳定的情况下，能覆盖的 URL 数量就会变少。对于页数较多的站点，这个差异会慢慢累积。
把每个页面当成一次传输机会：省下来的字节，可以留给更需要被发现的页面。
可以顺手检查的几个点
- 用查看源码或命令行工具，看 HTML 的原始大小和 gzip 压缩后的大小；
- 搜一下正文第一句在源码里出现的位置，估算它前面堆了多少内容；
- 确认 script 与 style 是否压缩、是否可以缓存；
- 检查占位内容有没有以大量空 DOM 的形式写在源码里。
收敛体积的几个做法
- 公共脚本合并压缩，并配上缓存头，让蜘蛛重复访问时不必重新下载全部内容；
- 页面里只放当前页面需要的数据，其余按需请求；
- 减少不参与索引的装饰性区块在源码中的重复；
- 图片、字体用外链资源，而不是内联的 Base64。
什么时候不必太在意
如果站点只有几十个页面，抓取频次充足，体积带来的影响通常不明显，优先级可以排在内容与内链之后。页面数量多、更新频繁、抓取预算偏紧的站点，才更值得先处理体积和正文位置。
这些调整不会立刻改变抓取结果，但会降低蜘蛛单次访问的成本。当站点规模变大、抓取次数有限时，省下来的这部分消耗，往往就是能多抓几个页面的空间。