preload对fcp有真实提升的媒体资源仅两类：as="image"（首屏lcp候选图）和as="font"（内联css中@font-face直接引用且用于首屏文本的字体），其他媒体preload反而拖慢fcp。
rel="preload" 对 FCP 有真实提升，但仅限于特定资源类型和正确用法；加错 as、漏 crossorigin 或预加载非关键资源，反而拖慢 FCP。
哪些媒体资源 preload 后真能压低 FCP？
不是所有“媒体”都值得 preload。FCP 只关心“第一个文本或图像何时渲染出来”，所以只有两类资源的 preload 能直接缩短它：
-
as="image"：首屏<img>的src地址，且该图是 LCP 候选元素（比如 banner 图、主标题图） -
as="font"：被内联 CSS 直接引用的字体文件（如@font-face中的url()），且该字体用于首屏文本
其他媒体——比如 video、audio、懒加载图片、非首屏图——preload 不仅不贡献 FCP，还会抢占带宽，推迟真正影响 FCP 的资源下载。
为什么 as="image" 的 preload 容易失效？
Chrome 109+ 支持 fetchpriority="high"，但前提是 as 和资源实际用途必须对齐。常见断点：
- 写了
<link rel="preload" href="/hero.jpg" as="image">，但页面里用的是<img src="/hero.webp">→ 路径不一致，缓存无法复用，触发两次请求 - 用了
srcset，但preload指向了某个固定尺寸（如/hero-1200w.jpg），而设备实际匹配的是/hero-768w.jpg→ 浏览器不会复用，等于白加 - 没加
fetchpriority="high"→ 即使as="image"正确，Priority 在 Network 面板里仍可能是 Medium，弱网下起效甚微
验证方式：DevTools → Network → 筛选该图片名 → 查看 Initiator 列是否为 preload，Priority 是否为 Highest 或 High。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
字体 preload 后 FCP 还高？三个静默失败点
FOIT/FOUT 没改善，大概率不是没加 preload，而是以下任一条件未满足：
- 漏了
crossorigin属性：哪怕字体和 HTML 同域，也必须写<link rel="preload" href="/fonts/inter.woff2" as="font" crossorigin>，否则浏览器丢弃已加载字体 -
type值与服务端返回的 MIME 不一致：Nginx 返回Content-Type: font/woff2，但标签里写type="font/woff"→ 缓存不命中，字体重新拉取 - CSS 里
@font-face的url()路径和preload的href字符串不完全相同（比如一个带.woff2后缀，一个没带；一个含 query 参数，一个不含）→ 浏览器视为不同资源
这些错误都不报 JS 错，Network 面板里资源显示 200，但字体就是不应用——只能靠对比 Performance.getEntriesByType('resource') 中该字体的 duration 和 renderBlocking 字段来定位。
FCP 提升量级和上线前必验项
在真实弱网（3G，RTT 300ms）下，正确配置的 as="image" 或 as="font" preload，FCP 通常可提前 200–450ms；但在 4G 或本地环境，收益可能低于 50ms，容易被噪声掩盖。
上线前必须确认三件事：
- 该
preload标签是否在 HTML 静态中（而非 JS 动态插入） - 对应资源是否真出现在首屏（Lighthouse 的 “Largest Contentful Paint element” 显示为该图或该文本块）
- 没有同时存在同 URL 的
<img src="...">或@font-face引用，且路径字符串逐字节一致
最容易被跳过的，是路径一致性 —— 构建工具自动加 hash、CDN 自动重写 URL、开发环境用代理路径，都会让 preload 和实际引用变成“看起来一样，实则不同”的两个资源。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
