DOM节点数直接影响解析耗时，浏览器单线程顺序解析，节点越多、嵌套越深，构建渲染树越慢；语义化标签应直接承载内容，避免冗余包裹，超150个无class/id的div即存优化空间。
DOM节点数直接影响解析耗时，不是“越语义越好”
浏览器解析HTML是单线程顺序执行，DOM节点越多、嵌套越深，构建渲染树的时间就越长。一个含 2000+ 节点的页面，解析时间可能比 500 节点页面多出 30–50ms —— 这在 LCP（最大内容绘制）指标里已是显著拖累。
语义化标签本身不慢，但滥用会变相增加节点数。比如用 <section><div><article><div><p> 套三层再加 wrapper div，实际只是展示一段文字，那 <article><p> 就足够。
- 检查开发者工具 Elements 面板，按
Ctrl+Shift+I→Ctrl+F搜索<div>，若单页超过 150 个且多数无 class 或 id，大概率存在冗余包裹 -
<header>、<nav>、<main>等语义标签应直接承载内容，避免再套一层<div class="container"> - Flexbox 或 Grid 布局能替代 80% 的“为了对齐而加的 div”，例如用
display: grid实现三栏布局，就不需要三个并列<div>再加 clearfix
CSS Grid/Flexbox 不是“写了就快”，关键在减少重排触发
现代布局方案本身不提升 HTML 解析速度，但能大幅降低后续 JS 操作和样式计算引发的重排（reflow）频率。一旦你用浮动或绝对定位强行拼凑结构，哪怕 DOM 很扁平，每次 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>，却加上 media="(min-width: 768px)"，结果这些规则被浏览器当作异步加载处理 —— 它们不会参与首次渲染，等于白写。
内联 CSS 必须是无条件生效的、影响首屏像素绘制的规则。任何带 media、@import、@layer 的代码，都会让浏览器跳过内联优化路径。
- 用工具如
critters提取 critical CSS 时，确认输出不含@media块；手工提取时，删掉所有非all或未指定 media 的规则 -
<style media="print">这类声明不会阻塞屏幕渲染，但也不该放进 critical 区域 - 如果首屏需响应式行为（如移动端折叠导航），用 JS 检测
window.innerWidth+ class 切换，别依赖内联 media 查询
脚本放 </body> 前 ≠ 安全，document.write() 仍会阻塞
把 <script> 移到 </body> 前确实能避免阻塞 DOM 构建，但若脚本内部调用 document.write()（尤其老 SDK 或广告代码），浏览器会清空当前文档并重开 parser，导致已解析的 HTML 全部作废。
这种问题在 DevTools 的 Network 面板里看不到请求失败，但在 Performance 面板能看到 “Parse HTML” 时间异常拉长，且 Main 线程长时间处于 idle 后突然爆发式工作。
- 用
console.error拦截全局document.write：在页面最顶部加<script>document.write = function() { console.error('document.write called!'); }</script> - 第三方脚本无法修改时，用
async+type="module"包裹（模块脚本默认 defer），或改用动态import()加载 - Webpack/Vite 构建时开启
devtool: 'source-map'，方便定位哪一行触发了 write
