关键渲染路径（CRP）是白屏时间的直接决定者，优化核心在于精准识别并移除阻塞点：用Chrome DevTools Performance面板录制加载，重点观察Parse HTML→Recalculate Style→Layout链路中的长空白或红色警告；Parse HTML耗时高说明HTML体积大或含同步script/link；Recalculate Style前长等待表明关键CSS未就绪，需查Network中Initiator为parser的CSS；Layout频繁触发则因JS强制同步布局。
关键渲染路径（CRP）不是理论概念，而是白屏时间的直接决定者——只要它卡在某一步，用户就只能干等。优化 CRP 不是“多做点事”，而是精准识别并移除阻塞点。
如何用 DevTools 定位 CRP 阻塞点
Chrome DevTools 的 Performance 面板是唯一能还原真实 CRP 流程的工具。录制页面加载后，重点看 Parse HTML → Recalculate Style → Layout 这段是否出现长空白或红色警告条。
-
Parse HTML耗时高：说明 HTML 体积大、嵌套深，或中间插入了同步<script>或未加media的<link rel="stylesheet"> -
Recalculate Style前有长等待：大概率是关键 CSS 未就绪，检查 Network 面板中Initiator列为parser的 CSS 请求 -
Layout频繁触发：说明 JS 在 DOM 就绪后立即读取 offsetTop/scrollHeight 等布局信息，强制浏览器提前计算
内联 CSS 的边界与风险
内联首屏 CSS 能消除一次请求，但不是越多越好。超过 10KB 的内联 CSS 会显著拖慢 HTML 解析，且无法被缓存复用。
- 只内联真正影响首屏像素绘制的样式，比如
.hero、.header、按钮基础状态，不包括@import、媒体查询内样式、动画 keyframes - 内联后必须移除对应外链
<link rel="stylesheet">，否则样式重复应用，可能引发意外交互 - 避免在内联 CSS 中写
url()引用外部字体或图片——这些仍会发起新请求，失去内联意义
defer 和 async 的实际执行时机差异
两者都让脚本异步下载，但执行时机完全不同，选错会导致 JS 报错或功能失效。
立即学习“前端免费学习笔记（深入）”；
-
defer：脚本下载与 HTML 解析并行，执行时机在 DOM 构建完成后、DOMContentLoaded事件前，且保持 script 标签顺序 —— 适合 Vue/React 初始化、API 请求等依赖 DOM 的逻辑 -
async：脚本下载完立刻执行，可能早于 DOM 就绪，也不保证顺序 —— 仅适合 analytics.js、埋点 SDK 这类无 DOM 依赖、可乱序执行的代码 - 兜底方案是把
<script>放在</body>前：DOM 肯定已就绪，但无法控制执行顺序，且对流式渲染不友好
preload 的 as 属性为什么不能省
没加 as 的 <link rel="preload"> 会被浏览器当成普通脚本处理，无法参与 CSSOM 或字体加载流程，等于白写。
-
as="style"：让预加载的 CSS 提前参与 CSSOM 构建，而不是等到 parser 遇到才开始解析 -
as="font"：配合crossorigin，避免字体加载失败（字体资源需跨域请求） -
as="script"：仅用于后续动态 import 的核心 chunk，不要 preload 整个 bundle —— 会抢占带宽，挤占关键 CSS/JS 下载
CRP 优化最难的部分不是技术手段，而是判断“什么是首屏关键”：它取决于真实用户视口、设备 DPR、网络延迟，而不是设计师给的“第一屏截图”。每次上线前，务必在 3G 模拟环境下用真实设备验证，否则所有优化都只是纸上谈兵。
