聊頁面加载優化时，大家首先想到图片、脚本、字体和服務器响應。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 体积不需要天天盯着，但可以在模板改版、編輯器升級、批量導入内容之後做一次抽查。把它和站内連結、标题描述、抓取日誌等自查放在同一張清單里，按季度或按版本過一遍，通常就能發現那些悄悄長出来的冗余。頁面轻一点，蜘蛛拿到的正文更靠前，讀者等待的時間也更短，這些收益不需要夸張的承诺，做完自然能感受到差別。