预加载字体、首屏背景图、关键css及首帧图可真正提升fcp；因其本被css或js延迟发现，preload能提前触发请求，解决“浏览器发现太晚”瓶颈，而错加非首屏资源反而挤占带宽拖慢fcp。
预加载特定媒体资源（如字体、首屏背景图、关键 CSS）确实能提升 FCP，但效果取决于是否真正解决了“浏览器发现太晚”这个瓶颈——不是所有 link rel="preload" 都对 FCP 有正向贡献，加错反而拖慢。
哪些 media 资源 preload 后真能提前 FCP？
FCP 受限于“首个文本/图片/背景图渲染完成”的时间点。只有那些本该在 HTML 解析完就立刻用、但被藏在 CSS 或 JS 里导致发现延迟的资源，preload 才有效：
-
@font-face中的.woff2字体：不 preload 就等 CSS 下载解析完才发起请求，直接拖长 FOIT，FCP 延后 - 内联
<style></style>里的background-image: url(...)hero 图：parser 看不见 URL，直到样式计算阶段才触发，preload 可提前拉取 - 首屏
<picture></picture>中明确指定的<source type="image/webp"></source>：srcset是运行时解析的，preload 能抢在 layout 前把 WebP 拿到 - 关键 CSS 文件本身（
as="style"）：尤其当它体积大、且未内联时，preload +onload替换可避免阻塞渲染
as 属性写错或漏写，FCP 不升反降
as 不是装饰字段，它决定请求优先级、CORS 行为和缓存分区。写错等于没写，甚至更糟：
-
as="font"必须配crossorigin，否则 Chrome/Safari 加载完也丢弃（即使同源），字体仍 FOIT，FCP 不变 -
as="style"必须加onload="this.onload=null;this.rel='stylesheet'"，否则只下载不注入，CSS 不生效，FCP 延迟 -
as="image"不能带srcset或sizes，只适合固定尺寸/格式的单图；对普通<img src>无效，不如用fetchpriority="high" - 漏写
as→ 浏览器按默认fetch处理，Priority 显示Low，跟没写一样
为什么预加载非首屏图片或 analytics.js 会拉低 FCP？
FCP 是首屏指标，只关心“第一个内容块渲染完成”。preload 的本质是抢占带宽和连接数：
- 预加载轮播图第二张图、懒加载模块的 JS、第三方统计脚本：
analytics.js—— 它们不参与首屏渲染，却挤占了关键资源的 TCP 连接和带宽 - Chrome Network 面板里看
Initiator列：如果大量preload请求排在document或script前面，但对应资源又不参与首次绘制，就是典型带宽干扰 - 实测建议：禁用 cache 后刷新，对比
FCP时间戳；若加了 preload 反而变慢，八成是预加载了不该加载的东西
真正影响 FCP 的不是“有没有 preload”，而是“有没有把浏览器发现太晚、但首屏立刻要画的东西，提前塞进 pipeline”。字体、内联背景图、关键 CSS、<picture></picture> 首帧图——这些才是值得动刀的地方；其余一律交给 prefetch 或自然发现机制更稳妥。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
