排查抓取問题时，多數人先看服務器、DNS、robots。這些确實是高频原因，但還有一類問题常被忽略：頁面本身的 HTML 太重。它不一定让頁面打不開，却會让解析、渲染和抓取都變得吃力。
HTML 太重意味着什么
浏览器和抓取程序拿到 HTML 後，要先把它解析成 DOM 树，再從中渲染頁面、提取正文與連結。文件越大、节点越多、嵌套越深，這一步消耗的時間就越長。對訪客来说是白屏時間變長，對抓取来说是在同样的時間预算里能處理的頁面變少。
需要强調的是，体积和节点數只是观察指标，不是评分公式。结构清晰、语义完整的頁面，即使节点多一些也没有問题；真正要警惕的是大量不承担任何职责的冗余结构。
自查一：單頁 HTML 体积
在無缓存狀態下查看頁面源碼，另存為文件後看大小。一個正文几百字的詳情頁，HTML 通常在几十 KB 量級；如果明顯超出，且多出来的部分主要来自模板而非内容，就值得進一步拆開看看。
常见的膨胀来源包括：
- 同一套样式在每個頁面里重复輸出一遍；
- 把整份列表資料或配置直接塞進頁面；
- 用 base64 把图片寫進 HTML；
- 被注释掉的舊模块長期保留在源碼里；
- 第三方组件自带的全量样式和脚本，實际只用到其中一小部分。
自查二：DOM 节点數量與嵌套深度
在開發者工具的元素面板里可以看节点統計，也可以用一段脚本統計頁面上的元素總數，观察各類模板之間的差异。
- 是否存在大量空容器，只用来做間距或清除浮動；
- 栏目列表是否一次性把几十上百條记錄全部渲染出来；
- 基础组件是否层层包裹，同一块内容外面套了五六层壳；
- 隐藏区域是否仍在完整輸出内容，只是用样式藏了起来。
自查三：内联资源與重复輸出
内联能省請求，但用過头會反噬。可以按下面几步過一遍：
- 統計頁面里内联样式块和脚本块的數量與總字符數；
- 確認同一段公共样式是否在每個頁面重复輸出；
- 看脚本是否在解析阶段就阻塞了後續内容的處理；
- 检查是否有图片、字体被轉成文本直接寫進 HTML。
自查四：模板里的歷史包袱
改版频率越高的站点，模板里的存量問题往往越多。常见的情况有：新舊两套模板同时輸出；埋点、广告位、推荐位在無内容时仍然輸出完整结构；上线时临时加的調试代碼被遗忘。這些内容對訪客不可见，但都會被真實地解析一遍。
怎么记錄與對比
自查的價值在于對比。建议挑選首頁、栏目頁、列表頁、詳情頁各一到两個代表 URL，在改動前後各测一次，记錄体积和节点數，形成一份可复用的基线。只看首頁往往會有誤導，真正重的通常是列表和詳情模板。
常见的優化方向
- 把重复出現的公共样式與脚本抽到统一位置，避免每個頁面重新輸出；
- 長列表改用分頁或按需加载，而不是一次性铺開；
- 頁面只輸出首屏需要的資料，其余通過接口获取；
- 清理被注释的舊代碼和已下线的模块，前提是確認無人依赖；
- 合並無意义的包装层，但不要為了减少节点而牺牲语义结构。
提醒：体积小、节点少本身不是目标。可訪問性、语义结构和後期维護成本同样重要，不要為了數字好看而删掉影响阅讀和理解的标簽。
把 HTML 体积和 DOM 结构纳入例行自查，和检查 robots、站点地图、日誌一样，属于日常运维的一部分。它不會立刻带来什么變化，但能减少很多说不清原因的解析缓慢和抓取吃力的状况。