关键渲染路径优化核心是解决资源阻塞而非单纯提速：和同步会中断html解析与绘制，导致白屏；需用chrome devtools performance和network面板识别parser触发的阻塞资源，内联首屏css、异步加载非关键css，并依据coverage面板真实覆盖率提取关键样式。
关键渲染路径不是“慢”，而是“卡在错的位置”——<link rel="stylesheet"> 和同步 <script></script> 会中断 HTML 解析与绘制，哪怕 DOM 已就绪，用户仍看到白屏。优化不是压缩体积，是控制浏览器「先看到什么、先加载什么、先执行什么」。
怎么识别哪个资源在阻塞首屏渲染
打开 Chrome DevTools → Performance 面板 → 录制一次页面加载，重点看 Parse HTML 后是否被 Recalculate Style 或 Layout 长时间挂起；再切到 Network 面板，筛选 css 和 js，看 Initiated by 列是不是 parser：如果是，说明这个资源是在 HTML 解析中途被同步拉取的，大概率是关键阻塞点。
-
parser触发的请求 = 渲染阻塞源，必须处理 -
script或other触发的请求 = 异步加载，通常不阻塞首屏 - 即使 CSS 文件已下载完成，只要没解析完，
render tree就无法生成，FCP 就不会触发
为什么 <link rel="stylesheet"> 会卡住整个渲染流程
CSS 是渲染树的必要输入，浏览器必须等所有关键 CSS 解析完成，才能和 DOM 合成渲染树。默认 <link rel="stylesheet"> 是「阻塞解析、阻塞渲染」的——它会让 HTML 解析暂停，直到 CSS 下载并解析完毕。
- 内联首屏 CSS 到
中，可跳过网络请求，立即参与样式计算 - 非关键 CSS 用
<link rel="preload" as="style" onload="this.onload=null;this.rel='stylesheet'">异步加载 - 避免在
中写<link rel="stylesheet">，这会导致解析器反复回退重排
同步 <script></script> 怎么破坏关键渲染路径
同步脚本会暂停 HTML 解析、暂停 DOM 构建，还会等待 CSSOM 就绪（因为 JS 可能调用 getComputedStyle）。这意味着一个放在 里的同步 <script></script>，可能同时拖住 DOM、CSSOM、渲染树三者。
- 把 JS 移到
底部，是最简单有效的解法 - 必须放
的脚本，加defer（保持执行顺序，不阻塞解析）或async（无序执行，适合独立分析脚本如统计代码） - 避免在同步脚本里访问
document.styleSheets或getComputedStyle，这会强制触发 CSSOM 构建，放大阻塞
内联 CSS 和异步加载的边界在哪
内联不是越多越好。Chrome 对内联 CSS 的解析开销是线性增长的，超过 ~10KB 会明显拖慢样式计算；而异步加载非关键 CSS 又不能晚到影响交互。真实项目中，边界由首屏 DOM 结构决定，不是靠猜。
- 用 Lighthouse 的 “Eliminate render-blocking resources” 建议定位哪些 CSS 实际参与了首屏渲染
- 用
coverage面板（More Tools → Coverage）跑一次首屏操作，看哪些 CSS 字节真正被用到 - 不要把整站 CSS 内联，只提取
html、body、.header、.hero等首屏可见节点的规则
最容易被忽略的点：关键资源判定必须基于真实首屏 DOM 结构，而不是文件名或目录层级。一个叫 common.css 的文件，如果首屏根本没用到其中任何选择器，它就不在关键路径上；反过来，一个叫 lazy-modal.css 的文件，如果首屏弹窗默认展开，它就是关键资源——别信名字，信覆盖率数据。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
