HTML结构问题是页面卡顿高频主因：DOM深度超6层、语义混乱、div堆叠、table内嵌div等会显著拖慢FCP，甚至阻塞主线程；需用DevTools检查DOM深度并重构。
页面卡顿经常是 HTML 标签结构直接引发的，不是“可能”，而是高频主因——DOM 深度超 6 层、语义混乱、div 堆叠、table 内嵌 div 等写法，会让浏览器在低端机上光构建节点就卡住首屏。
DOM 深度超 6 层会卡在哪一步
浏览器解析 HTML 时，每层嵌套都要创建节点、匹配样式、计算布局。在骁龙 425 或旧版 Android WebView 中，DOM 深度 >6 就会显著拖慢首次内容绘制（FCP），甚至触发主线程长时间阻塞。
- 用 Chrome DevTools → Elements 面板右键任意节点 →
Show DOM tree查看实际深度；超过 8 层必须重构 - 禁用为兼容老 IE 写的
<div class="wrapper"><div class="inner"><div class="content"> 套路，现代 CSS 已无需这类包裹 <li><code><td> 里别套 <code><div>：表格单元格内样式计算成本高，嵌套后极易强制重排 <h3>语义标签缺失导致解析变慢</h3> <p>纯 <code>div布局不只难维护，还会让浏览器失去轻量解析路径。语义标签如<header></header>、<nav></nav>、<main></main>虽不提速，但 DOM 节点更少、样式匹配更快。- 用
<section></section>替代三层<div> 堆叠，尤其在响应式模块中效果明显 <li> <code><picture></picture>内多个<source></source>都带loading="lazy"，某些 WebView 会误判为全部非关键，导致首帧空白 - 首屏关键图（如 Logo、Banner 第一帧）必须显式写
loading="eager"，否则可能被延迟到滚动后才加载 - Network 面板刷新后看 HTML 的
transfer size：若 >500KB，基本是内联 Base64 图片或大段<script></script>/<style></style>拖累解析 - Elements 面板右键根节点 →
Show DOM properties，查depth值；同时观察是否有大量重复class="clearfix"、class="row"这类无语义包裹 - 临时屏蔽某块 HTML：在 Elements 中右键外层容器 →
Edit as HTML，删掉中间几层再刷新，看卡顿是否消失
快速定位是不是 HTML 结构问题
别猜，用 Network + Elements 双面板交叉验证：
立即学习“前端免费学习笔记（深入）”；
真正容易被忽略的是：DOM 深度和语义混乱不会报错，控制台永远安静，但它们在低端机上造成的卡顿是真实且不可绕过的——优化必须从结构本身下手，而不是等 JS 执行完再找补。
- 用
