关键渲染路径不是“慢”，而是“卡在错的位置”：和同步阻塞html解析与渲染树生成，导致fcp延迟、白屏久，即使domcontentloaded很快；关键资源须基于首屏真实结构判定，不可猜测。
关键渲染路径不是“慢”，是“卡在错的位置”——首屏白屏久，往往因为一个 <link rel="stylesheet"> 或同步 <script></script> 拦在了渲染树生成前。
为什么 DOMContentLoaded 快但页面还是白屏？
因为 DOMContentLoaded 只表示 DOM 树构建完成，不等于能画出像素。浏览器必须等 CSSOM 构建完，才能合成渲染树；而默认的 <link rel="stylesheet"> 会阻塞首次绘制（FP）和首内容绘制（FCP），哪怕 CSS 文件已下载完毕，只要没解析完，就停在白屏或 FOUC 状态。
常见错误现象：
- FCP > 3s，但
DOMContentLoaded在 800ms 就触发 - 文字先裸奔显示，100–300ms 后突然套上样式（FOUC）
- Performance 面板里
Parse HTML→Recalculate Style出现长空白段
怎么识别哪些 CSS/JS 是关键资源？
不能靠猜，得看加载链路是否参与首屏渲染：
- 打开 Chrome DevTools → Network 面板 → 筛选
css和js→ 查看Initiator列：若为parser，说明是 HTML 解析中途同步拉取，大概率是关键资源 - CSS 中含
body、.hero、.header、.login-form等首屏选择器的规则属于关键 CSS；含@import、media="(min-width: 1024px)"的通常不是 - JS 若只用于轮播初始化、表单校验或埋点，且不操作首屏 DOM，就不是关键 JS
内联关键 CSS 有哪些硬约束？
内联不是把整个 main.css 塞进 <style></style>，而是提取真正影响首屏的最小规则集，且体积必须严控：
- 内联体积建议 ≤ 2–5 KB；超 ~1KB 会显著拖慢 TTFB 和初始 HTML 解析，尤其弱网下
- 禁止在内联
<style></style>中写@import—— 它会立刻发起同步网络请求，退化为外部阻塞加载 - 服务端无法缓存内联样式，每次 HTML 更新都得重传全部内容，所以必须用工具（如
critters、purgecss + html-webpack-plugin）自动提取，别手写
defer 和 async 到底该选哪个？
二者都解除对 HTML 解析的阻塞，但执行时机不同，选错会导致 JS 找不到 DOM 节点或样式未就绪：
-
defer：脚本并行下载，等 DOM 解析完、DOMContentLoaded前按顺序执行 —— 适合依赖 DOM 结构和首屏样式的主逻辑（如init.js） -
async：下载完立即执行，不保证顺序 —— 适合完全独立、无依赖的脚本（如统计、广告tracker.js） - 注意：
async脚本若在 DOM 解析完成前执行，document.getElementById可能返回null；defer脚本若依赖尚未注入的 CSS 变量（如var(--theme-color)），可能拿到 fallback 值
真正容易被忽略的点是：关键资源的判定必须基于真实首屏结构，而非开发环境的“看起来像”。同一份 CSS，在 PC 端可能是关键，在移动端可能全是非关键；同一份 JS，在 SSR 页面里可能无需执行，在 CSR 页面里却是首屏渲染的命脉。优化不是贴膏药，而是持续验证加载链路与用户可见内容的映射关系。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
