排查抓取问题时，多数人先看服务器、DNS、robots。这些确实是高频原因，但还有一类问题常被忽略：页面本身的 HTML 太重。它不一定让页面打不开，却会让解析、渲染和抓取都变得吃力。
HTML 太重意味着什么
浏览器和抓取程序拿到 HTML 后，要先把它解析成 DOM 树，再从中渲染页面、提取正文与链接。文件越大、节点越多、嵌套越深，这一步消耗的时间就越长。对访客来说是白屏时间变长，对抓取来说是在同样的时间预算里能处理的页面变少。
需要强调的是，体积和节点数只是观察指标，不是评分公式。结构清晰、语义完整的页面，即使节点多一些也没有问题；真正要警惕的是大量不承担任何职责的冗余结构。
自查一：单页 HTML 体积
在无缓存状态下查看页面源码，另存为文件后看大小。一个正文几百字的详情页，HTML 通常在几十 KB 量级；如果明显超出，且多出来的部分主要来自模板而非内容，就值得进一步拆开看看。
常见的膨胀来源包括：
- 同一套样式在每个页面里重复输出一遍；
- 把整份列表数据或配置直接塞进页面；
- 用 base64 把图片写进 HTML；
- 被注释掉的旧模块长期保留在源码里；
- 第三方组件自带的全量样式和脚本，实际只用到其中一小部分。
自查二：DOM 节点数量与嵌套深度
在开发者工具的元素面板里可以看节点统计，也可以用一段脚本统计页面上的元素总数，观察各类模板之间的差异。
- 是否存在大量空容器，只用来做间距或清除浮动；
- 栏目列表是否一次性把几十上百条记录全部渲染出来；
- 基础组件是否层层包裹，同一块内容外面套了五六层壳；
- 隐藏区域是否仍在完整输出内容，只是用样式藏了起来。
自查三：内联资源与重复输出
内联能省请求，但用过头会反噬。可以按下面几步过一遍：
- 统计页面里内联样式块和脚本块的数量与总字符数；
- 确认同一段公共样式是否在每个页面重复输出；
- 看脚本是否在解析阶段就阻塞了后续内容的处理；
- 检查是否有图片、字体被转成文本直接写进 HTML。
自查四：模板里的历史包袱
改版频率越高的站点，模板里的存量问题往往越多。常见的情况有：新旧两套模板同时输出；埋点、广告位、推荐位在无内容时仍然输出完整结构；上线时临时加的调试代码被遗忘。这些内容对访客不可见，但都会被真实地解析一遍。
怎么记录与对比
自查的价值在于对比。建议挑选首页、栏目页、列表页、详情页各一到两个代表 URL，在改动前后各测一次，记录体积和节点数，形成一份可复用的基线。只看首页往往会有误导，真正重的通常是列表和详情模板。
常见的优化方向
- 把重复出现的公共样式与脚本抽到统一位置，避免每个页面重新输出；
- 长列表改用分页或按需加载，而不是一次性铺开；
- 页面只输出首屏需要的数据，其余通过接口获取；
- 清理被注释的旧代码和已下线的模块，前提是确认无人依赖；
- 合并无意义的包装层，但不要为了减少节点而牺牲语义结构。
提醒：体积小、节点少本身不是目标。可访问性、语义结构和后期维护成本同样重要，不要为了数字好看而删掉影响阅读和理解的标签。
把 HTML 体积和 DOM 结构纳入例行自查，和检查 robots、站点地图、日志一样，属于日常运维的一部分。它不会立刻带来什么变化，但能减少很多说不清原因的解析缓慢和抓取吃力的状况。