关键渲染路径卡住是因为DOM和CSSOM未在正确时间点就绪；结构顺序、资源加载时机、内联策略任一出错都会导致首屏白屏。
关键渲染路径卡住，不是因为HTML写得不够“规范”，而是DOM和CSSOM没在正确的时间点就绪——结构顺序、资源加载时机、内联策略，三者错一个，首屏就白屏。
为什么放在
浏览器确实会并行下载CSS，但不会等它下载完才继续解析HTML；真正卡住的是「首次绘制」：没有CSSOM，渲染树就合成不了，哪怕DOM早已构建完毕。只要
-
link rel="stylesheet"默认按media="all"处理，浏览器视其为关键资源，必须等它解析完成才能推进渲染树 - 如果CSS里含
@import，会串行加载被导入文件，打断并行，且必须等上级CSS解析到该行才发起请求 - 把
link写在<body>里更糟：HTML解析器会回退重排，触发额外开销
内联关键CSS的硬性位置和体积约束
内联不是插哪儿都行，也不是越多越好。位置错、体积超，反而拖慢TTFB和初始解析。
-
<style>必须紧跟<meta charset>之后，是<head>中第一个非meta标签；否则会被前面的link阻塞 - 禁止在
<style>里用@import——它会发起同步网络请求，等于新增一个阻塞点 - 内联CSS体积建议≤1KB；实测在3G弱网下，从1KB涨到5KB会使HTML主文档传输延迟增加400ms以上
- 提取关键CSS不能靠截取
main.css前几KB，而要基于真实首屏DOM节点+视口尺寸动态捕获（如用critters或criticalCLI驱动Puppeteer）
同步<script>怎么同时拖住DOM、CSSOM和渲染树</script>
同步脚本不只是暂停HTML解析——它还会强制等待CSSOM就绪，因为JS可能调用getComputedStyle()或访问document.styleSheets。
立即学习“前端免费学习笔记（深入）”；
- 放在
<head>里的同步<script>，会同时阻塞DOM构建、CSSOM构建、渲染树合成 - 移到
</body>底部是最简单解法；必须放<head>的，加defer（保持执行顺序）或async（适合统计类独立脚本） - 避免在同步脚本里读取布局信息（如
offsetHeight）或调用getComputedStyle()，这会强制提前构建CSSOM，放大阻塞
HTML结构如何影响重排成本与首屏感知
结构本身不阻塞渲染，但它决定了后续Layout阶段的计算压力。DOM节点越深、样式依赖越复杂，重排就越慢，LCP指标越差。
- 首屏关键内容（标题、主图、按钮）必须写在HTML靠前位置；浏览器流式解析，靠后的内容即使DOM已就绪，也可能因Layout压力延迟绘制
- 避免深层嵌套选择器（如
article section div p em）和通配符（* {}），它们不拖慢CSS解析，但显著增加CSSOM匹配开销 - 对频繁切换显示/隐藏的模块（如Tab面板），用
hidden属性或aria-hidden+CSS控制，而非反复增删class触发样式重算 - 动画优先用
transform和opacity，它们走合成线程，不触发Layout；用top/left或width则必然触发重排
最容易被忽略的其实是「内联CSS的位置刚性」和「@import的隐式同步行为」——它们不报错、不抛异常，但会在DevTools Performance面板里安静地把Parse HTML挂起几百毫秒。优化不是堆技巧，是让每个资源在浏览器流水线里找到它该出现的那个精确时间点。
