关键渲染路径卡在DOM与CSSOM合成前，因<link rel="stylesheet">会强制暂停HTML解析、阻塞DOM构建，直至CSS下载并解析完成CSSOM；即使小文件或缓存命中仍存在确定性阻塞，且多CSS按顺序串行加载。
关键渲染路径卡在哪儿，首屏就停在哪儿——不是 HTML 写得不够“语义化”，而是 DOM 和 CSSOM 合成前的等待没被打破。
为什么 link rel="stylesheet" 一出现，HTML 解析就暂停
浏览器解析 HTML 时，遇到 <link rel="stylesheet"> 会立刻中断 DOM 构建，发起 CSS 请求，并阻塞后续所有解析，直到该 CSS 下载完成、解析出 CSSOM。这不是网络慢导致的延迟，而是浏览器的强制行为。
- 即使 CSS 文件只有 1KB 且命中本地缓存，仍要验证
Cache-Control头、解析内容，产生确定性阻塞 - 多个
<link>按顺序串行加载：第二份 CSS 的下载必须等第一份 CSSOM 构建完才开始 -
media属性没写，默认按media="all"处理，浏览器视其为关键资源，无法跳过
内联 <style> 为什么不能直接复制 main.css
内联样式绕过网络请求，让 DOM 和 CSSOM 可并行构建，但内联 ≠ 全量搬运。超过 ~10KB 的内联 CSS 会显著拖慢 TTFB 和初始 HTML 解析，尤其在弱网下。
- 真正该内联的，只是首屏像素生成所需的最小规则集合：比如
.hero、.logo、.login-form的尺寸、颜色、display等基础声明 - 含
@import的 CSS 绝对不能内联——它会触发同步网络请求，立刻退化为外部阻塞加载 - 伪类（
:hover）、媒体查询断点（@media (max-width: 768px)）、动态 class（.is-loading）容易漏掉，必须用critters或purgecss + html-webpack-plugin自动提取
script 放 <head> 还是 </body> 不重要，属性才决定阻塞行为
位置只是表象，真正起作用的是脚本的加载语义。默认 <script src="app.js"></script> 是同步阻塞的：HTML 解析停 → 下载 JS → 执行 JS → 继续解析。
立即学习“前端免费学习笔记（深入）”；
-
defer：JS 下载与 HTML 解析并行，执行推迟到 DOM 解析完成之后、DOMContentLoaded之前，适合业务初始化脚本 -
async：JS 下载并行，但执行时机不可控，可能打断 DOM 构建，只适合统计类、无 DOM 依赖的脚本 - 放在
</body>前不等于不阻塞——此时 DOM 已接近构建完，用户感知略好，但本质仍是同步阻塞，且无法保证多脚本执行顺序
Chrome DevTools 里真正该盯住的两个阻塞信号
别只看 Lighthouse 分数。CRP 问题必须回归浏览器原生行为验证。
- Performance 面板录制后，重点看
Parse HTML→Recalculate Style是否出现长空白段——那是 CSSOM 构建卡住的直接证据 - Network 面板筛选
css和js，看Initiator列：若显示parser，说明是 HTML 解析中途同步拉取，大概率是关键阻塞点 - FCP > 3s 但
DOMContentLoaded在 800ms 触发？说明 DOM 构建快，但 CSSOM 或 JS 执行拖住了渲染树生成
真正难的不是知道该做什么，而是判断哪条 CSS 规则属于“首屏必需”——它取决于真实设备视口、用户进入路径、甚至服务端下发的 AB 实验分组。工具能提取选择器，但无法替代人工校验首屏像素。
