性能导向的html布局核心是减少浏览器计算、重排、重绘和阻塞；嵌套过深会增加dom节点、样式计算与树遍历开销，如...即属典型错误。
性能导向的HTML布局，核心不是“怎么画得漂亮”，而是“怎么让浏览器少算、少重排、少重绘、少阻塞”。很多看似微小的结构选择，会在首屏渲染时间、内存占用、滚动流畅度上产生可观测差异。
避免嵌套过深的语义化容器
用 <header></header>、<nav></nav>、<main></main> 是对的，但不等于可以无节制嵌套。浏览器解析 HTML 时，每个元素都要生成 DOM 节点、计算样式、布局、绘制——嵌套每多一层，就多一次树遍历和样式继承开销。
- 常见错误：把整个导航栏包在
<header><div class="wrapper"><nav><div class="container">...</div></nav></div></header>里，实际只需<header><nav>...</nav></header> - 建议：语义标签本身已具备隐含的容器语义，
<nav></nav>内部不需要再套<div class="nav-inner">；同理，<code><main></main>直接承载内容区块即可 - 影响：Chrome DevTools 的
Layers面板中可见额外图层叠加；Lighthouse 的 “Avoid an excessive DOM size” 建议常源于此 - 验证方式：在 Chrome DevTools 的
Rendering→Paint flashing开启后，table 布局区域常持续高亮，而 Flex/Grid 区域闪烁更短、更分散 - 关键区别：
<script src="a.js"></script>和<script async src="a.js"></script>行为完全不同；async不保证执行顺序，defer保证顺序但不阻塞解析 - 最佳实践：非关键 JS 放在
table 用于布局会触发强制同步布局
即使你只写一个 <table> 且没填数据，只要它参与布局流（display: table），浏览器就必须等整行所有单元格宽度确定后才能开始绘制——这会打断渲染流水线，造成 layout thrashing。
<ul><li>典型场景：用 <code><table> 实现“三栏等高布局”或“垂直居中 hack”
<li>替代方案：Flexbox 的 <code>align-items: stretch 或 Grid 的 grid-template-rows: 1fr 不依赖内容尺寸，可异步计算
script 标签位置直接影响首屏渲染阻塞
<script></script> 默认是 parser-blocking 的——HTML 解析器遇到它就会暂停，去下载、编译、执行 JS，再继续解析。哪怕脚本只读取 document.body，也会卡住 DOM 构建。
