html嵌套超6层会直接拖慢fcp 200ms以上，因浏览器流式解析时每层均增加dom创建、样式匹配与布局计算开销；需用语义化标签降深、控节点数≤800，并禁用webview三项高危配置。
HTML代码质量差，高动态渲染页面大概率在低端设备上卡死、闪退或交互失灵——不是JS逻辑有问题，而是浏览器在解析你写的结构时就已超负荷。
嵌套超过6层直接触发重排风暴
移动端低端机上，
<div><div><div><div><div><div><p>内容</p><div class="aritcle_card flexRow artxards"> <div class="artcardd flexRow"> <a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill5117" title="HTML Extract"><img src="https://img.php.cn/upload/skill/000/000/081/179033952939354.jpg" alt="HTML Extract" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a> <div class="aritcle_card_info flexColumn"> <a rel="nofollow" href="/xiazai/skill5117" title="HTML Extract" class="overflowclass">HTML Extract</a> <p class="overflowclass">使用 MinerU 从 HTML 页面和文件中提取内容，将 HTML 转换为保持标题、列表、表格及文本层次结构的干净、结构化 Markdown。F...</p> </div> <a rel="nofollow" href="/xiazai/skill5117" title="HTML Extract" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span> </a> </div> </div></div></div></div></div></div></div> 这种结构会让首次内容绘制（FCP）延迟200ms以上。浏览器每解析一层，就要多做一次DOM节点创建 + 样式匹配 + 布局计算，而动态渲染页面往往还要叠加Vue/React的diff和重绘。
- 用 Chrome DevTools → Elements 面板右键任意节点 →
Show DOM properties 查看 <code>depth值，超过6就该砍 - 能用
<section></section>、<header></header>、<main></main>替代三层<div> 堆叠的，优先替换；它们不增加解析开销，还能压低 DOM 节点总数 <li><code><td> 里别再套 <code><div>：表格单元格内样式计算成本高，嵌套后极易在 flex 容器中触发强制同步重排 <h3>语义化标签不是“写得好看”，是绕过解析陷阱</h3> <p>写 <code><nav></nav>和写<div class="nav"> 对解析耗时几乎没差别，但它能避免一堆真实坑： <ul> <li> <code><header></header>必须语义上属于某个节段（<article></article>或<section></section>），否则屏幕阅读器会把全页导航+搜索+登录读作一块 “banner”，失去层次；单独丢一个<footer></footer>在 DOM 底部却不包裹内容，部分安卓 WebView 直接忽略其语义 -
<time datetime="2026-06-30"></time>这类标记 iOS Safari 会识别并提供「添加到日历」快捷操作，且不增加任何解析负担 - 服务端渲染（SSR）场景下，语义化标签能让
next/image自动注入loading="lazy"和宽高属性，省掉 JS 补充逻辑
动态插入 HTML 片段必须走 <template></template> 路线
直接 innerHTML = htmlStr 插入动态内容，每次都要重新解析、构建 DOM、触发样式计算——高频更新时，帧率立刻掉到 30fps 以下。
- 必须用
document.importNode(template.content, true)克隆，不能appendChild(template)（否则原模板被移走，下次就没得用了） -
template.content是DocumentFragment，不能直接querySelector，得先挂载或用querySelectorAll在 fragment 上查 - 模板里
<script></script>和<style></style>会被忽略；事件监听器必须克隆后手动绑定，ID 冲突要重写（比如加时间戳后缀） - 服务端返回的 HTML 片段，必须只含纯结构（无
/），且要用临时template元素设innerHTML再取.content，否则标签闭合错误会导致 DOM 异常
content-visibility: auto 不是开关，是带条件的性能杠杆
在长列表或折叠面板里加 content-visibility: auto，90% 的人漏掉关键前提：它必须配 contain-intrinsic-size，否则滚动条跳变、内容闪入、页面塌陷。
-
contain-intrinsic-size值必须是具体像素，如contain-intrinsic-size: 48px（单行）或contain-intrinsic-size: 300px / 200px（Chrome 122+ 支持宽高比）；设为auto或空值等于没写 - 子元素写了
height？那个值会覆盖contain-intrinsic-size的高度，但宽度不受影响；所以卡片高度不均时，取最小高度 × 1.2，宁可留白，别让撑开后重排 - SSR 页面里，别在 HTML 静态输出时就加
content-visibility: auto；等 hydration 完成、JS 控制状态后再设，否则首屏看到大片空白 - 含
position: fixed子元素、用ResizeObserver或IntersectionObserver、父容器设overflow: hidden的场景，加了反而更卡——这些不是 bug，是隔离行为的必然结果
真正卡住高动态渲染的，从来不是某一行 JS，而是 HTML 结构在解析阶段就埋下的重排隐患、DOM 节点膨胀和资源加载错序。改结构比调 JS 更快见效，但容易被忽略——因为没人盯着 depth 值报警，也没人检查 template.content 是否真被克隆了。
