关键路径阻塞源是同步加载的CSS/JS：Network面板按Initiator排序找parser标记的资源，Performance面板看Parse HTML后是否紧接Recalculate Style/Layout；内联关键CSS须精准、≤1KB、位于meta后首个style标签；非关键CSS用preload+onload或media="print"异步加载；defer适合依赖DOM/样式的脚本，async仅用于完全独立脚本。
关键路径阻塞资源不消除，首屏就卡在白屏——不是资源慢，是浏览器被你写的 <link rel="stylesheet"> 或同步 <script> 主动拦下了。
怎么看哪个 CSS/JS 正在阻塞首屏渲染
别猜，直接看 Chrome DevTools 的真实链路：
- 打开 Network 面板 → 刷新页面 → 点击
Initiator列排序，重点关注标为parser的.css和.js请求：它们是在 HTML 解析中途被同步拉取的，就是关键阻塞源 - 切到 Performance 面板 → 录制加载 → 找
Parse HTML后是否紧跟着长时间的Recalculate Style或Layout：有，说明 CSSOM 没就绪；没 DOM 变化但白屏，大概率是 JS 在等未解析完的样式 - 注意一个陷阱：
DOMContentLoaded很快 ≠ 首屏已出。它只代表 DOM 构建完成，而FCP（首屏内容绘制）必须等 CSSOM 就绪才能触发
内联关键 CSS 为什么总做不对
内联不是把 main.css 复制粘贴进 <style>，而是精准塞入首屏像素生成必需的最小规则集：
-
<style>必须是<head>中<meta charset>之后的**第一个标签**，否则浏览器会先去加载后面那个<link rel="stylesheet"> - 体积控制在 gzip 后 ≤1KB：超了会拖慢 TTFB，弱网下多一个 RTT；实测从 1KB 到 5KB，3G 下首屏延迟增加 400ms+
- 禁用
@import：哪怕写在<style>里，也会触发同步网络请求，立刻退化为阻塞加载 - 别手动截取 CSS 文件开头 ——
.hero、.login-form这类选择器才该留，@keyframes、暗色模式、display: none区块全删掉 - 工具推荐用
critters（Vite）或critical（Webpack），但上线前务必人工验证：断网刷新，还能正常显示的元素，其样式才值得保留
非关键 CSS 怎么异步加载才不闪、不卡
目标是让非首屏样式“按需加载、无感激活”，而不是简单加个 async：
立即学习“前端免费学习笔记（深入）”；
- 用
<link rel="preload" as="style" href="non-critical.css" onload="this.onload=null;this.rel='stylesheet'">：预加载 + onload 时切换为样式表，避免 FOUC - 更稳妥的写法是配合
media="print"：<link rel="stylesheet" href="non-critical.css" media="print" onload="this.media='all'">，初始不参与渲染，JS 触发后才激活 - 千万别对整个
vendor.js或main.js做preload：它已被defer覆盖，再 preload 属于冗余调度，反而抢带宽 - 如果用了动态
import()加载 CSS（比如按路由拆分），modulepreload完全无效——它只解析静态字面量路径，对模板字符串或拼接路径毫无感知
script 标签加 defer 还是 async？执行时机决定成败
二者都解除 HTML 解析阻塞，但错配会导致脚本静默失败：
-
defer：脚本按顺序下载，DOM 解析完、DOMContentLoaded前执行 —— 适合主逻辑、依赖 DOM 节点或首屏样式（如轮播初始化、表单校验） -
async：下载完立即执行，无序、不保证顺序 —— 只适合完全独立的脚本，比如统计埋点、错误监控 - 常见坑：
app.js里调用了vendor.js导出的函数，但vendor.js是defer，app.js是async：执行时vendor.js可能还没就绪 - 更隐蔽的问题：
async脚本可能早于关键 CSS 解析完毕就执行，导致getComputedStyle返回空值，动画错位或布局异常
真正难的不是识别阻塞点，而是判断「这个 CSS 是否真影响首屏像素」——Coverage 面板的灰色高亮只是参考，真实首屏视口、设备 DPR、SSR 渲染结果都会影响关键样式边界。每次提取后，必须在真实弱网环境断网验证。
