关键请求链路由HTML结构和资源加载方式自然形成，精简核心是砍掉非首屏必需的同步加载、提前交付卡渲染的关键资源；关键资源包括阻塞渲染的style、无async/defer的script、首屏img；判断依据是DevTools中Initiator为parser且DOMContentLoaded前完成；实操需内联首屏CSS（≤10KB）、JS加defer/async、关键资源preload并带as属性；避免preload滥用、HTTP/2误判、SSR重复外链等常见错误。
关键资源请求链路不是靠“写出来”的，而是被 HTML 结构和资源加载方式自然形成的；精简它的核心动作是：砍掉非首屏必需的同步加载、提前交付真正卡渲染的那几个资源。
哪些资源会构成关键请求链路
浏览器在解析 HTML 时，遇到某些标签会立即发起网络请求，并且阻塞后续 DOM 构建或渲染树生成。这些就是关键资源：
-
<link rel="stylesheet">：无条件阻塞渲染，直到 CSSOM 构建完成 -
<script>（无async或defer）：阻塞 HTML 解析，也常阻塞渲染 -
<img>在首屏可视区内：虽不阻塞解析，但影响 LCP，属于关键渲染路径中的“关键字节”环节 -
<link rel="preload" as="style">若没配onload切换为stylesheet，它只是下载，不参与 CSSOM 构建——不算进关键链路
怎么判断一个资源是不是关键的
别猜，用 Chrome DevTools 的 Network 面板看 Initiator 列：
- 显示为
parser：说明是 HTML 解析过程中触发的同步请求，大概率是关键资源 - 显示为
script或other：通常是 JS 动态插入或事件触发，一般不卡首次渲染 - 检查该资源是否在
DOMContentLoaded前就已下载完成：如果拖到后面才完成，它可能不是关键路径上的瓶颈，而是后续交互依赖
再配合 Performance 面板录制，看 Parse HTML → Recalculate Style → Layout 这段有没有明显空档或长任务——空档说明资源没来，长任务说明 CSS/JS 太重。
立即学习“前端免费学习笔记（深入）”；
精简链路的实操动作
目标不是“删资源”，而是让浏览器能用最少的往返、最小的字节、最短的等待，画出首屏。重点做三件事：
- 把首屏必须的 CSS 内联进
<head>，体积控制在 ≤10KB；避免@import，它会触发额外请求 - 所有非首屏 JS 加
defer（保证顺序）或async（独立无依赖）；<script>标签绝不能放在<head>里且无属性 - 对首屏用到的字体、主样式表、大图，用
<link rel="preload" as="font">、<link rel="preload" as="style">、<link rel="preload" as="image">提前拉取，但必须带as属性，否则浏览器按脚本处理
示例错误写法：<link rel="preload" href="main.css"> —— 缺 as="style"，浏览器不会把它当样式资源优先解析。
容易被忽略的坑
精简链路最常翻车的地方不在技术本身，而在边界判断：
- 把
preload当成万能加速器：预加载一个 2MB 的bundle.js，反而挤占带宽，让main.css下载变慢 - 误以为 HTTP/2 就不用精简：多路复用只解决并发问题，不解决资源是否必要、是否阻塞的问题
- SSR 页面里内联了 CSS 却没移除对应的外链
<link rel="stylesheet">：样式重复应用，还多一次请求
关键路径不是越短越好，而是刚好够画出首屏——少一点，用户看不到内容；多一点，白屏时间就延长。这个“刚好”，得靠真实设备 + 真实网络条件反复测。
