preload对FCP无直接提升，因其仅提前下载资源而不参与DOM构建、样式计算或绘制；仅当预加载的as="image"或as="font"资源严格匹配首屏实际使用的图片或字体时，才可能间接优化FCP。
为什么加了 preload 还是没压低 FCP
因为 preload 本身不触发绘制，它只提前下载资源。FCP（First Contentful Paint）取决于首个文本或图像节点完成渲染的时刻，而这个时刻由 HTML 解析、DOM 构建、样式计算、布局、绘制整条链路决定。preload 插不进这条链——它既不插入 DOM，也不参与样式匹配，更不触发重排重绘。实测中常见现象是：加了 <link rel="preload" as="image" href="/hero.jpg">，但页面里用的是 <img src="/hero.webp">，Network 面板里能看到两次请求，FCP 完全没动。
真正能靠占位符影响 FCP 的只有两类资源
不是所有“关键资源”都对 FCP 有效。能缩短 FCP 的，仅限于那些**直接决定首个内容块何时就绪**的资源：
-
as="image"：仅当该图是首屏<img>的src值，且是 LCP 候选元素（如 banner、主标题图），并且路径、格式、srcset匹配完全一致 -
as="font"：仅当字体被内联 CSS 中的@font-face直接引用，且该字体用于首屏文本（比如<h1>标题），同时满足crossorigin、type、URL 字符串三者严格一致
其他类型——as="script"、as="style"、as="video"、懒加载图、非首屏图——加了 preload 不仅不帮 FCP，还会抢带宽，拖慢 HTML/CSS 下载，反而让 FCP 推迟。
验证 preload 是否真起效的三个必查点
别信“写了就生效”。Chrome DevTools 里必须手动确认：
立即学习“前端免费学习笔记（深入）”；
- Network 面板筛选目标资源名 → 看
Initiator列是否为preload，而不是parser或script - 右键表头勾选
Priority→ 关键图应显示Highest或High；若仍是Medium，说明fetchpriority="high"没配或浏览器不支持（需 Chromium 112+） - Performance 面板录制后，用
performance.getEntriesByType('resource')查该资源的renderBlocking字段：若为true且duration很短，说明它确实参与了首屏阻塞链；若为false，大概率是白加
最容易被忽略的静默失败点
这些错误几乎都不报 JS 错，Network 显示 200，但 FCP 就是不动：
-
<link rel="preload" as="font">漏了crossorigin属性 → 字体解码失败，回退系统字体，FOIT 消失，LCP 延迟，FCP 表面正常实则失真 -
@font-face里的url()和preload的href差一个.woff2后缀或 query 参数 → 浏览器视为两个资源，缓存不复用 - 用了
srcset或sizes，但preload指向固定尺寸图 → 设备匹配不到，请求白发
真正卡住 FCP 的，从来不是“有没有加 preload”，而是 HTML 解析是否被同步脚本阻塞、内联 CSS 是否超 15KB、DOM depth 是否 ≥7、iframe 是否在初始 HTML 里带 src——这些才是优先要动的根因。
