link rel="preload" 对 fcp 没有直接提升作用——它仅提前下载资源，不参与 dom 构建、样式计算或绘制，而 fcp 取决于首个内容块（文本/图像）完成渲染的时刻；其真正价值在于优化 lcp，尤其当首屏最大元素依赖被预加载的资源时。
link rel="preload" 对 FCP 没有直接提升作用——它不渲染内容，也不触发 paint。FCP 只关心“第一个文本或图像何时被绘制”，而 preload 本身只是下载资源，不参与 DOM 构建、样式计算或绘制流程。
为什么 preload 不改变 FCP 数值
FCP（First Contentful Paint）由浏览器在完成以下步骤后标记：解析 HTML → 构建 DOM → 计算样式 → 布局 → 绘制首个内容块（text、img、svg、canvas 等）。link rel="preload" 只影响资源下载时机，既不插入元素，也不触发重排重绘。
- 预加载一张 hero 图（
as="image"）但未在<img src>中使用，FCP 不会提前 - 预加载关键 CSS（
as="style"）但没通过onload切换为rel="stylesheet"，样式不生效，FCP 不受影响 - 预加载字体（
as="font"）但页面首屏文字用的是系统字体，FOIT 不发生，FCP 与字体无关
preload 实际影响的是 LCP，不是 FCP
真正受益的是 LCP（Largest Contentful Paint），尤其当首屏最大元素依赖被 preload 的资源时：
-
<img src="hero.jpg">的 LCP 时间 = 下载完成时间 + 解码时间；若提前preload，下载阶段前移，LCP 可提前 200–600ms（实测常见于 3G/4G 网络） -
@font-face字体未 preload 时，首屏标题可能 fallback 到系统字体（FCP 正常），等字体加载完再重绘（LCP 延迟）；preload 后 LCP 能锁定为 Web Font 渲染时刻 - 内联
<style></style>中 background-image 引用的 hero 图，浏览器无法自动发现，必须靠preload as="image"才能让该图参与 LCP 计算并尽早就绪
错用 preload 反而拖慢 FCP
带宽竞争是隐性杀手——尤其在弱网下，preload 抢占了本该用于 HTML、CSS 或 JS 的初始 TCP 连接和带宽：
- 对非首屏图片（如懒加载轮播图）加
preload，会延迟关键 CSS 下载，导致 CSSOM 构建晚，DOM 渲染链路拉长，FCP 推迟 - 多个
as="script"预加载但后续未实际执行（比如条件未满足），浪费连接数，HTTP/2 多路复用优势被稀释 -
as="fetch"加了但没配crossorigin，请求失败后仍占用连接队列，间接拖慢其他资源初始化
真正要优化 FCP，得盯住 HTML 解析速度、关键 CSS 内联程度、JS 阻塞点——preload 是个好工具，但它只服务 LCP 的“最后一公里”，不是 FCP 的加速器。最容易被忽略的，是以为加了 preload 就等于页面变快，结果监控里 FCP 没动，LCP 也没提，全是带宽被自己占满了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
