dom节点数直接影响解析耗时，浏览器单线程顺序解析，节点越多、嵌套越深，构建渲染树越慢；语义化标签应直接承载内容，避免冗余包裹，超150个无class/id的div即存优化空间。
DOM节点数直接影响解析耗时，不是“越语义越好”
浏览器解析HTML是单线程顺序执行，DOM节点越多、嵌套越深，构建渲染树的时间就越长。一个含 2000+ 节点的页面，解析时间可能比 500 节点页面多出 30–50ms —— 这在 LCP（最大内容绘制）指标里已是显著拖累。
语义化标签本身不慢，但滥用会变相增加节点数。比如用 <section><div><article><div>
<p> 套三层再加 wrapper div，实际只是展示一段文字，那 <code><article><p></p></article> 就足够。
- 检查开发者工具 Elements 面板，按
Ctrl+Shift+I→Ctrl+F搜索<div>，若单页超过 150 个且多数无 class 或 id，大概率存在冗余包裹 <li> <code><header></header>、<nav></nav>、<main></main>等语义标签应直接承载内容，避免再套一层<div class="container"> <li>Flexbox 或 Grid 布局能替代 80% 的“为了对齐而加的 div”，例如用 <code>display: grid实现三栏布局，就不需要三个并列<div> 再加 clearfix <h3>CSS Grid/Flexbox 不是“写了就快”，关键在减少重排触发</h3> <p>现代布局方案本身不提升 HTML 解析速度，但能大幅降低后续 JS 操作和样式计算引发的重排（reflow）频率。一旦你用浮动或绝对定位强行拼凑结构，哪怕 DOM 很扁平，每次 <code>offsetWidth读取或 class 切换都可能触发全量重排。真正起效的前提是：布局逻辑完全由 CSS 控制，JS 只负责数据/状态变更，不碰
style.left、style.top或频繁调用getBoundingClientRect()。- Grid 容器内子项增删，只要不改变
grid-template-areas或显式grid-column，浏览器通常只做重绘（repaint），不重排 - Flex 容器设
flex-wrap: wrap后动态插入子项，比用 JS 计算位置 +position: absolute插入安全得多 - 避免在循环中读写同一元素的 layout 属性（如先读
offsetHeight，再改className），这会强制同步布局计算
内联关键 CSS 时，
<style></style>里的媒体查询会失效很多人把首屏样式内联进
<style></style>，却加上media="(min-width: 768px)"，结果这些规则被浏览器当作异步加载处理 —— 它们不会参与首次渲染，等于白写。内联 CSS 必须是无条件生效的、影响首屏像素绘制的规则。任何带 media、@import、@layer 的代码，都会让浏览器跳过内联优化路径。
- 用工具如
critters提取 critical CSS 时，确认输出不含@media块；手工提取时，删掉所有非all或未指定 media 的规则 -
<style media="print"></style>这类声明不会阻塞屏幕渲染，但也不该放进 critical 区域 - 如果首屏需响应式行为（如移动端折叠导航），用 JS 检测
window.innerWidth+ class 切换，别依赖内联 media 查询
脚本放
- Grid 容器内子项增删，只要不改变
