蜘蛛抓取页面时，第一件事是下载 HTML 源码。如果一份列表页的源码有 800KB，其中绝大部分是内联样式、统计脚本和各种重复结构，那么真正用于读内容的资源就被压缩了。页面体积本身不等于权重，但过大的体积会消耗抓取预算，也会影响首屏渲染和用户阅读体验。
一次页面体积自查，重点看什么
HTML 源码大小
- 首页、栏目页、详情页各取 3 到 5 个样本，分别记录压缩前与压缩后的源码体积。
- 单页 HTML 压缩后明显超过 300KB，就值得翻一翻原因，不必急着定死标准，先看构成。
- 留意后台编辑器导出的内联样式、字体 base64、未裁剪的 JSON 数据块，它们常常是体积大头。
内联资源是否每页重复下发
- base64 小图、内联 SVG 图标、整段内联 CSS 与 JS，如果被写进模板，就会出现在每个页面上。
- 公共样式和脚本更适合外链并交给缓存，而不是每次随 HTML 一起重复传输。
冗余与重复结构
- 导航、面包屑、页脚是否在每页完整输出两三遍，尤其是多套模板拼装时容易出现。
- 注释掉的旧代码、隐藏的填充文本、废弃的模板片段，长期留在源码里并不会带来收益。
- 移动端与 PC 端如果是两套 DOM 同时输出，再用 CSS 隐藏其中一套，体积会接近翻倍。
抓取与渲染层面的连带影响
- 体积变大后，单次抓取耗时变长，同样一段时间内能抓的 URL 数量下降。
- 如果页面依赖前端渲染，源码里几乎没有正文，问题会比单纯体积大更麻烦。
- HTML 解析和 DOM 构建同样变慢，移动端用户的首屏等待会直接感受到。
可以动手的压缩方向
- 开启服务端压缩，优先使用 brotli 或 gzip，并去掉模板里多余的空行与注释。
- 合并重复的模板片段，让公共区块在每个页面只输出一次。
- 把 base64 小图改回独立图片文件，交给浏览器缓存和 CDN。
- 清理未使用的 CSS 规则和早已不用的老版本 JS 库。
- 首屏用不到的脚本延后加载，不要把统计、弹窗、客服组件全部塞在头部。
自查节奏与记录方式
不必每天测一次，但每次调整模板、接入新组件之后，抽查几个典型页面的体积变化是有必要的。建议固定记录三项：压缩后体积、请求数量、排在前几位的体积贡献块。过一段时间把这份记录和服务器日志里的抓取情况对照，看响应时间和抓取频次有没有实际变化。
提示：减体积不是删内容。优先处理重复、废弃、纯装饰性的代码，正文段落、标题层级和必要的语义标签不要为了好看的数字而牺牲。
小结
页面体积是一项容易被忽略的基础指标。它不直接决定页面能不能被收录，但会影响蜘蛛下载和解析页面的效率，也会影响用户的第一次感受。把重复结构和无用代码清一清，是成本不高、见效相对直接的一次站点整理。