性能导向的HTML布局核心是减少浏览器计算、重排、重绘和阻塞；嵌套过深会增加DOM节点、样式计算与树遍历开销，如<header><div class="wrapper"><nav><div class="container">...即属典型错误。
性能导向的HTML布局，核心不是“怎么画得漂亮”，而是“怎么让浏览器少算、少重排、少重绘、少阻塞”。很多看似微小的结构选择，会在首屏渲染时间、内存占用、滚动流畅度上产生可观测差异。
避免嵌套过深的语义化容器
用 <header>、<nav>、<main> 是对的，但不等于可以无节制嵌套。浏览器解析 HTML 时，每个元素都要生成 DOM 节点、计算样式、布局、绘制——嵌套每多一层，就多一次树遍历和样式继承开销。
- 常见错误：把整个导航栏包在
<header><div class="wrapper"><nav><div class="container">.../nav></div></header>里，实际只需<header><nav>.../header> - 建议：语义标签本身已具备隐含的容器语义，
<nav>内部不需要再套<div class="nav-inner">；同理，<main>直接承载内容区块即可 - 影响：Chrome DevTools 的
Layers面板中可见额外图层叠加；Lighthouse 的 “Avoid an excessive DOM size” 建议常源于此
table 用于布局会触发强制同步布局
即使你只写一个 <table> 且没填数据，只要它参与布局流（display: table），浏览器就必须等整行所有单元格宽度确定后才能开始绘制——这会打断渲染流水线，造成 layout thrashing。
- 典型场景：用
<table>实现“三栏等高布局”或“垂直居中 hack” - 替代方案：Flexbox 的
align-items: stretch或 Grid 的grid-template-rows: 1fr不依赖内容尺寸，可异步计算 - 验证方式：在 Chrome DevTools 的
Rendering→Paint flashing开启后，table 布局区域常持续高亮，而 Flex/Grid 区域闪烁更短、更分散
script 标签位置直接影响首屏渲染阻塞
<script> 默认是 parser-blocking 的——HTML 解析器遇到它就会暂停，去下载、编译、执行 JS，再继续解析。哪怕脚本只读取 document.body，也会卡住 DOM 构建。
立即学习“前端免费学习笔记（深入）”；
- 关键区别：
<script src="a.js">和<script async src="a.js">行为完全不同；async不保证执行顺序，defer保证顺序但不阻塞解析 - 最佳实践：非关键 JS 放在
</body>前；必须前置的（如 polyfill）加defer；仅用于监听 DOMContentLoaded 的脚本，优先用DOMContentLoaded事件而非document.write - 容易被忽略的坑：
<script type="module">默认行为等价于defer，但若模块内 import 动态资源（如import('./lazy.js')），仍可能触发后续网络请求延迟首屏完成
图片与媒体元素未做加载控制会拖慢 LCP
Largest Contentful Paint（LCP）指标直接受首屏最大元素加载速度影响。而 <img>、<video> 等元素若未声明尺寸或未启用懒加载，会导致浏览器反复重排重绘。
- 必须做：
<img width="600" height="400">—— 提前告知渲染引擎占位尺寸，避免 layout shift - 推荐做：
<img loading="lazy">对非首屏图片生效；但注意 Safari 旧版本不支持，需 fallback 到 IntersectionObserver - 慎用：
<picture>中多个<source>若未配media或type，浏览器可能并行下载全部候选资源，浪费带宽
性能不是靠加工具链堆出来的，而是从第一个 <html lang="zh"> 就该考虑的约束条件。最慢的布局，往往藏在最“安全”的语义标签嵌套里，或者最“方便”的 script 放置位置中。
