深层嵌套会放大重排成本，因其导致父容器尺寸变化时需递归校验每层子元素的位置、尺寸和层叠关系，触发同步Layout，引发滚动卡顿、getBoundingClientRect延迟及LCP恶化。
为什么深层嵌套结构会放大重排成本
深层嵌套本身不拖慢 HTML 解析，但会让 Layout 阶段的计算量指数级上升——尤其当父容器尺寸变化时，浏览器必须递归校验每一层子元素的位置、尺寸和层叠关系。比如 article > section > div > ul > li > a 这种链式结构，一旦 section 的 max-width 被 JS 动态修改，整个子树都可能触发同步 Layout。
常见错误现象包括：滚动卡顿、getBoundingClientRect() 调用延迟明显、LCP 指标在移动端 3G 下突然恶化。
- 避免无语义的
<div>套娃，用<main>、<nav>、<section>等自带隐式布局边界的语义标签替代 - Flexbox 或 Grid 容器内，少用
position: absolute+top/left定位，改用align-self或grid-row等原生布局属性 - DOM 节点数超 1500 时，慎用
offsetHeight、getComputedStyle()等强制同步 Layout 的读操作
哪些 CSS 写法会隐式延长 Layout 时间
CSS 解析快，但某些规则会把 Layout 推向主线程瓶颈。它们不阻塞 CSSOM 构建，却让浏览器在绘制前反复重算布局。
典型场景：首屏按钮点击后，下拉菜单展开缓慢；Tab 切换时内容区域闪烁或错位。
立即学习“前端免费学习笔记（深入）”；
-
* {}通配符选择器本身不慢，但它让所有节点都参与样式匹配，增大 CSSOM 树体积，间接抬高 Layout 内存开销 -
display: table、float、inline-block触发 BFC 创建，增加布局上下文切换成本，比flex或grid多 2–3 倍 Layout 时间 - 用
transform和opacity做动画，不触发 Layout；而改width、height、top就会强制 Layout + Paint + Composite 全流程 -
visibility: hidden保留文档流位置，开销远低于display: none（后者会触发 DOM 重排）
media 属性如何真正解耦非关键 CSS
media 不是“加个属性就变异步”，它生效的前提是媒体查询**当前不匹配**。浏览器看到 media="print" 或 media="(min-width: 1024px)"，会立刻以低优先级异步加载，且不阻塞渲染树合成。
容易踩的坑：把 media="screen" 当作“安全写法”——其实它默认匹配所有设备，等同于 media="all"，照样阻塞。
- 非首屏模块（如
.modal、.chart-container）的样式应拆出独立文件，并设media="(min-width: 0px) and (max-width: 0px)"占位 - 暗色模式、打印样式、桌面端专属布局，直接用对应媒体查询，无需 JS 干预
- 动态切换主题时，不要用
@import加载新 CSS，而是用 JS 创建新<link rel="stylesheet">并插入<head>
内联关键 CSS 的边界在哪
内联不是“把 main.css 复制进 <style>”，而是提取首屏可见区域（viewport 内）所需的最小样式集。超了反而坏事：HTTP/2 帧大小限制约 14KB，gzip 后超过 8KB 就可能触发额外分片；HTML 体积膨胀也影响 TTFB。
真实项目里最常被误塞进内联样式的是：全局动画 keyframes、未折叠的第三方组件样式、整套图标字体定义。
- 只包含
.hero、.nav、.lcp-image等首屏直接渲染的类，排除.modal、.footer、.pagination - 用
critters（Webpack）或vite-plugin-critical（Vite）自动提取，别手撸；提取后务必禁用缓存刷新验证 FCP 是否提前 - 内联部分不含
@import、不含外部字体声明（@font-face应走preload）、不含变量 fallback 链过长的var(--x, var(--y, ...))
结构与 CSS 的协作，核心不在“写得多规范”，而在“谁先到、谁管哪块、谁动了谁要重算”。很多性能问题藏在看似无害的 div 嵌套和 margin-top 里，而不是语法错误中。
