HTML解析与布局渲染强耦合，同步脚本阻塞解析、CSSOM未完成阻塞布局、强制同步布局引发卡顿，需用defer、避免@import、批量读写及Containment优化。
HTML结构解析和布局渲染不是两个独立环节，而是强耦合的流水线——改结构不调资源加载顺序，优化基本白做。
HTML解析被同步脚本阻塞时，布局渲染完全停摆
浏览器解析HTML生成DOM树的过程是单线程、自上而下的。一旦遇到没有async或defer的<script src="a.js"></script>，解析立刻暂停，等JS下载、编译、执行完才继续。此时CSSOM可能还没构建完，渲染树无法生成，布局和绘制自然卡死。
- 常见错误现象：
<head>里放未加defer的第三方统计脚本，FCP延迟直接+400ms+ - 真实场景：Vue/React项目中，
index.html里手动引入runtime.js却漏写defer，首屏白屏时间远超LCP阈值 - 验证方式：DevTools → Network → 看
index.html的“Waterfall”列，若script请求横跨整个HTML解析阶段，就是它在阻塞 - 修复建议：外部脚本统一用
defer；内联初始化逻辑（如data-layer注入）改用document.write替代方案，或推迟到DOMContentLoaded后
CSSOM构建不完成，布局阶段无法启动
CSS是渲染树的必要输入，没有完整的CSSOM，哪怕DOM树已就绪，浏览器也不会进入布局阶段。关键点在于：CSS资源虽不阻塞HTML解析，但会阻塞渲染树构建和后续所有渲染步骤。
- @import比
<link rel="stylesheet">慢不止一倍：它强制串行下载，main.css里两行@import实际等效于三次HTTP往返 - 错误写法：
<link rel="stylesheet" href="theme.css">放在<body>里——浏览器会立即阻塞渲染，但此时DOM可能已部分解析完毕，造成“样式闪动”或CLS突增 - 正确姿势：
<link rel="stylesheet">必须在<head>，且避免嵌套@import；首屏关键CSS提取后内联，<style>...</style>体积控制在14KB以内 - 兼容性注意：HTTP/2下多个
<link>并行效果更好，但旧版iOS Safari对preload + CSS的复用支持不稳定，as="style"不可省略
布局计算（Reflow）被频繁触发时，页面交互卡顿明显
布局不是只发生一次。任何读取元素几何属性（如offsetHeight、getBoundingClientRect()）后紧跟写操作（如改className），都可能触发强制同步布局（Layout Thrashing）。
立即学习“前端免费学习笔记（深入）”；
- 典型坑：
for循环里反复读el.offsetWidth再设el.style.left，每轮都触发重排 - 安全做法：批量读取（把所有
offset*集中一次取完），再批量写入；或用requestAnimationFrame把写操作推到下一帧 - 现代替代：用
CSS Containment（contain: layout paint）隔离子树，限制重排影响范围；但IE和旧版Safari不支持，需降级兜底 - 性能验证：Performance面板录制交互，看
Layout事件是否密集出现，火焰图中是否出现大量绿色长条
真正卡住渲染管线的，往往不是某段复杂CSS或巨量DOM节点，而是<script>没加defer、@import藏在第三方库CSS里、或者一个offsetTop调用放在了错误的循环位置——这些细节不查DevTools水fall图和performance火焰图，根本看不到。
