首屏白屏时间长而 DOMContentLoaded 早触发，是因为渲染需完成关键CSS加载、JS执行、样式计算、布局、绘制等步骤，即关键渲染路径（CRP）阻塞在render tree生成前；优化需聚焦资源加载时机与语义。
为什么首屏白屏时间长，DOMContentLoaded 却早就触发了？
因为浏览器渲染不只等 DOM 构建完成——它还要等关键 CSS 加载解析、关键 JS 执行、样式计算、布局、绘制。这个链条就是「关键渲染路径」（CRP）。白屏久，往往卡在 render tree 生成前：比如一个 <link rel="stylesheet"> 阻塞了后续所有渲染，哪怕 DOM 已就绪。
实操建议：
- 用 Chrome DevTools 的
Performance面板录制加载过程，重点关注Parse HTML→Recalculate Style→Layout这段是否被阻塞 - 检查 Network 面板中所有
css和js请求的Initiator列：若显示为parser，说明是 HTML 解析时同步加载，大概率是关键资源 - 把非首屏必需的 JS 改用
async或defer；CSS 中非首屏样式抽离，用media属性条件加载（如media="print"或自定义media="(min-width: 768px)"）
preload 和 prefetch 到底该在哪用？
preload 是告诉浏览器“这个资源马上就要用”，强制提前获取并尽早开始解析（如关键字体、首屏 CSS、核心 JS）；prefetch 是“可能之后会用”，优先级低，适合下一页的资源。
常见误用：
立即学习“前端免费学习笔记（深入）”；
- 对
logo.svg用prefetch—— 它属于首屏关键图像，应内联或preload+as="image" - 在
<head>里preload一个 2MB 的 Webpack bundle —— 浏览器会抢带宽，反而挤占关键 CSS/JS 的下载，得不偿失 - 没加
as属性：缺少as="style"的preload会被当成脚本处理，无法参与 CSSOM 构建
正确写法示例：
<link rel="preload" href="main.css" as="style" onload="this.onload=null;this.rel='stylesheet'"> <link rel="preload" href="Lato.woff2" as="font" type="font/woff2" crossorigin>
内联 CSS 和 JS 的边界在哪？
内联能消除 HTTP 请求，但会增大 HTML 体积、阻碍缓存复用。不是越小越好，而是要平衡「首次渲染速度」和「后续访问效率」。
推荐策略：
- 只内联首屏必需的 CSS（通常 ≤ 10KB），用工具如
critters（Vite/webpack）或Penthouse自动提取 - 避免内联含
@import的 CSS —— 浏览器仍需发起新请求，失去内联意义 - JS 绝对不要内联逻辑代码（如 React 渲染函数），仅可内联极小的运行时钩子（如
__INIT_DATA__注入） - 服务端渲染（SSR）场景下，内联 CSS 后记得移除对应外链
<link>，否则重复应用样式
为什么开了 HTTP/2 还要减少请求数？
HTTP/2 支持多路复用，但每个资源仍有头部开销、服务器排队、TLS 握手延迟。更关键的是：浏览器对同一域名的并发连接数仍有软限制（Chrome 通常 6–10 个），且资源发现仍依赖 HTML 解析顺序 —— 比如第 7 个 <link> 的 CSS，即使 HTTP/2 能并发，也要等前面 6 个标签解析完才被发现。
所以优化重点仍是「让关键资源早出现、早加载」：
- 把关键
<link rel="stylesheet">和<script>尽量放在<head>靠前位置（但不要在<meta charset>前） - 避免在 HTML 底部插入动态
<link>或<script>—— 它们会延迟关键资源发现 - 使用
resource hints（如dns-prefetch、preconnect）提前建立第三方域名连接，但别滥用：每个preconnect都会触发 TLS 握手，开销不小
真正影响 CRP 的，从来不是协议本身，而是你把哪些资源放到了 HTML 的哪个位置、用了什么加载语义。细节藏在 link 的 rel 和 as 里，不在“开了 HTTP/2 就万事大吉”的幻觉里。
