聊页面加载优化时，大家首先想到图片、脚本、字体和服务器响应。HTML 文档本身往往被当成“没多少东西”的一层，事实上，随着模板迭代和编辑器功能增加，一个普通内容页的 HTML 也能膨胀到几百 KB。它不如图片显眼，但每个页面都要传一次，叠加起来对抓取和访问体验都有影响。
HTML 体积为什么值得单独看
HTML 是页面的骨架，也是蜘蛛最先拿到的内容。如果骨架里塞了大量重复包裹、空标签、内联样式和注释，会出现几个问题：
- 传输体积变大，首字节之后的内容到达更慢；
- 解析和构建 DOM 的成本增加，移动端更明显；
- 正文在源码中的位置被推后，人工排查和程序提取都更费劲；
- 模板问题会在全站复制，一个页面多 30 KB，一万个页面就是不小的浪费。
这里说的不是要把 HTML 压到极限，而是避免无意义的重复。语义清晰、便于维护仍然优先。
常见的体积膨胀来源
1. 模板层层包裹
主题或框架常见“多层容器”写法：每个组件外面套 section、div、div、div，真正的内容被埋得很深。层级多不一定是错，但如果只是为样式服务，且每层都带长串 class 名，体积会累积。
2. 编辑器输出的冗余标记
富文本编辑器容易留下空段落、连续 br、无内容的 span、从其他文档粘贴来的内联样式。单篇不明显，栏目页或聚合页批量调用时就会放大。
3. 未压缩的空白与注释
开发环境中的缩进、换行和说明注释，在生产环境通常可以压缩。如果站点没有开启 gzip 或 brotli，空白也会按原样传输，虽可压缩后变小，但源码仍显臃肿。
4. 内联样式与脚本
为了减少请求，有时会把样式和脚本内联。适量内联没问题，但把整段样式表或统计代码逐页复制，就会让每个页面都背一份重复内容。
5. 重复的导航与页脚
全局导航、页脚、侧栏本身是必要的。但如果每个页面都展开大段站点链接、标签云或推荐模块，且这些模块对正文没有帮助，就值得评估是否精简。
怎么做一次 HTML 体积自查
- 先取样本。选首页、栏目页、详情页、标签页各一到两个，查看页面源码大小。不要只看浏览器开发者工具中的“传输大小”，也看一下未压缩体积。
- 对比同类页面。同模板的两篇文章，体积不应差出好几倍。如果差得多，重点检查正文中是否混入了多余样式、表格或嵌入内容。
- 检查模板输出。查看详情页和列表页的公共部分，确认没有重复输出同一段导航、同一组 meta 或重复的 JSON-LD。
- 看压缩是否生效。确认服务器对 HTML 启用了 gzip 或 brotli。可以在响应头中查看 content-encoding，注意不要只压缩 CSS 和 JS 而漏掉 HTML。
- 定位最大区块。把页面源码按区块大致拆分，找出占比最高的部分。多数情况下是模板框架、内联脚本或大段重复列表，而不是正文本身。
- 记录基线。精简前后各记一次体积，避免凭感觉判断。至少保留一个可回滚的版本。
精简时的几个注意点
- 不要为了减体积删掉有语义的标题层级、列表和表格结构，这些对内容和可访问性有价值。
- 不要盲目合并或移除正文中的段落标签，可能导致样式和提取逻辑出问题。
- 压缩空白和注释通常放在构建或服务端处理，不建议手工修改源模板，否则后续维护困难。
- 内联脚本和样式如果被多处复用，考虑抽成独立文件并设置缓存，而不是继续复制。
- 如果站点使用缓存插件或 CDN，确认精简后的页面仍然能正常更新，不会把旧版本长期留在边缘节点。
把体积检查放进日常流程
HTML 体积不需要天天盯着，但可以在模板改版、编辑器升级、批量导入内容之后做一次抽查。把它和站内链接、标题描述、抓取日志等自查放在同一张清单里，按季度或按版本过一遍，通常就能发现那些悄悄长出来的冗余。页面轻一点，蜘蛛拿到的正文更靠前，读者等待的时间也更短，这些收益不需要夸张的承诺，做完自然能感受到差别。