首屏白屏时间长但 DOMContentLoaded 早触发，说明关键渲染路径（CRP）卡在渲染树生成前，即关键CSS/JS未就绪，而非DOM未构建完成；需通过Coverage面板识别真正影响首屏绘制的资源，内联关键CSS（≤1KB）、异步加载非关键JS，并精准preload首屏必需资源。
首屏白屏时间长，但 DOMContentLoaded 很早就触发了？说明 CRP 卡在渲染树生成前，不是 DOM 没建好，而是关键资源没到位。重构加载优先级不是调顺序，而是让浏览器「先拿到、先解析、先用」真正影响首屏的那部分资源。
怎么识别哪些 CSS/JS 算“关键”资源
关键资源 = 首屏像素绘制前必须就绪的 HTML、CSS、JS。不是“用了就是关键”，而是“不用它，首屏就画不出来”。常见误判是把整张 main.css 当关键，结果拖慢 TTFB 和初始解析。
- 打开 Chrome DevTools → Coverage 面板（More Tools → Coverage），刷新页面，看 CSS 文件里实际被使用的字节占比；低于 30% 的基本可剥离
- 切到 Network 面板，筛选
css和js，看Initiator列：显示parser的才是 HTML 解析中途触发的同步加载，大概率是关键阻塞点 - 注意伪类和媒体查询：比如
:hover或@media (min-width: 768px)在桌面首屏不触发，但平板横屏访问时可能立刻生效——提取工具如critical或penthouse要配对 viewport 设置，否则漏规则
内联关键 CSS 的体积和时机控制
内联不是越多越好，超过 ~1KB 就开始反向拖慢首屏：HTML 主文档变大 → 弱网下 TTFB 延迟 → 初始字节到达更晚。而且服务端无法缓存，每次发布都得重传全部内联样式。
- 只内联首屏结构必需的规则：
.header、.hero-text、.primary-btn的基础尺寸、颜色、display，不包含动画、主题色切换、响应式断点 - 构建时用
critters（Webpack）或purgecss + html-webpack-plugin自动提取，别手写——手写容易漏媒体查询或动态 class - 配合
<link rel="preload" as="style" href="non-critical.css">提前拉取非关键 CSS，避免它 later 被 parser 发起时变成新阻塞点
JS 加载策略要按执行时机分层
async 和 defer 看似简单，但错配会直接卡住渲染树合成。关键 JS（比如影响首屏数据渲染的初始化逻辑）不能简单加 defer，而纯分析脚本（如 analytics.js）也不该放 <head> 里同步加载。
立即学习“前端免费学习笔记（深入）”；
- 首屏依赖的 JS（如 hydration 逻辑、关键 API 请求）建议用
<script type="module">+defer，现代浏览器能并行解析+延迟执行，且天然支持import按需加载 - 完全不影响首屏的 JS（埋点、广告、第三方 widget）必须加
async，且放在<body>底部或用fetch().then(() => import(...))动态导入 - 避免
<script>放在<head>里没加任何属性——这是最典型的 parser-blocking 行为，会中断 HTML 解析，等 JS 下载+执行完才继续
media 属性和 preload 的组合陷阱
media 不是“懒加载”，而是“条件加载”；preload 也不是万能加速器。两者混用不当，反而制造冗余请求或提前加载无用资源。
-
<link rel="stylesheet" href="print.css" media="print">是安全的：打印样式表只在打印时加载，不会阻塞屏幕渲染 -
<link rel="stylesheet" href="mobile.css" media="(max-width: 767px)">在桌面访问时仍会被 parser 发起请求（只是不应用），除非加rel="preload"+onload动态插入，否则仍是潜在阻塞点 -
<link rel="preload" as="script" href="non-critical.js">必须配onload或后续<script src="...">，否则只下载不执行，还占带宽
CRP 优化最难的不是技术动作，而是判断“这个资源到底要不要现在加载”。很多团队花时间压 gzip 大小，却放任一个 200KB 的 vendor.css 同步加载——它比压缩率更能决定用户第一眼看到什么。优先级重构的本质，是把浏览器当成一个有明确任务的协作者，而不是被动接收一堆文件的容器。
