DOM深度超6层时，应优先扁平化无语义、无样式、纯包裹的冗余标签，如三连div嵌套、语义标签被冗余容器包围、为样式硬塞的多层span；删除标准是向上无样式或事件绑定的空节点。
DOM深度超6层时，哪些标签必须优先扁平化
DOM树深度≥7就该动手，但不是所有嵌套都一样危险。真正拖慢渲染的是那些既无语义、又没样式、纯靠
-
<div class="wrapper"><div class="content"><div class="inner">——这种三连嵌套是重排放大器，JS改个padding会波及整棵子树 -
<main>被套在<section><div class="page">里——语义标签被冗余父容器包围，浏览器无法跳过其子树解析 -
<button><span><span><span>点击</span></span></span></button>——为加hover效果硬塞三层span，类名全靠CSS选择器定位，样式计算链翻倍
优先删掉的不是“最深那一层”，而是“向上找不到任何样式或事件绑定”的空节点。用DevTools右键→Show DOM properties查node.depth，再顺手跑document.querySelectorAll('div').length，超300个纯
语义化标签怎么用才真提速，而不是只图个好看
不是写了<header>就自动变快，关键看它是否参与了浏览器的内部优化路径。
-
<main>和<aside>设display: none时，浏览器直接跳过子树构建；普通<div>即使隐藏，仍要走完解析+样式计算全流程 -
<details><summary>替代手写展开收起的5层结构，能省掉JS控制逻辑和对应DOM节点- 把首屏标题、主按钮直接放在
<body>下一级，最多嵌套2层——这是Chrome实测getComputedStyle()卡顿从80ms降到12ms的关键阈值别为了语义强行改结构：如果一个
<article>里只有<p>和<img>，那它和<section>性能差异几乎为零；但若它被<div class="container">包着，反而多一层遍历。立即学习“前端免费学习笔记（深入）”；
html-to-pptx-converter下载使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
表格类长文档，不改分页也能提速的关键动作
6万行表格白屏1分钟，问题不在数据量，而在浏览器必须等整行
<td>收齐才建DOM。哪怕你只想要前10行，第11行缺个闭合标签，整个表格就卡死。- 确保
<tr>和<td>严格成对闭合——Vue/React模板里用v-for生成时，容易漏掉</td>导致解析中断 - 禁用
colspan/rowspan：跨行合并会强制浏览器回溯整表结构，实测开启后layout耗时涨3倍 - 真要流式渲染，别用
innerHTML +=拼接HTML字符串，改用DocumentFragment批量append，每批≤200行
更激进但有效的做法：把
<table>换成<div role="table">+display: grid，配合grid-template-columns模拟列宽，DOM节点数下降60%，且支持原生滚动锚点。为什么删了三层嵌套，页面还是卡
因为性能瓶颈常不在DOM本身，而在CSS选择器的回溯路径。删掉
<div class="nav">，但CSS还写着.page .header .nav .item a，浏览器照样从每个a往上验证4层祖先是否存在。- BEM类名如
nav__item--active本质是把结构“编译”进类名，让匹配降为单次查找 - SCSS里
&:hover嵌套5层，编译后仍是.menu .menu__item:hover这种高成本选择器 - 把修饰符提级：
menu__item--hover比依赖.menu:hover .menu__item快得多
最容易被忽略的一点：你花一小时删DOM嵌套，不如花五分钟检查
devtools → Styles面板 → 选中元素 → 看匹配的选择器链长度。链长＞4，就是下一个该砍的地方。 - 把首屏标题、主按钮直接放在
