必须写在中且路径与完全一致，配合as="image"和fetchpriority="high"才能抢在html解析前发起lcp图片请求；单独用fetchpriority或漏写as属性均无效。
怎么用 <link rel="preload"> 抢在浏览器解析完 HTML 前发起 LCP 图片请求
预加载不是“多加一行就变快”，而是要卡准浏览器预扫描器（preload scanner）的执行窗口——它只在 HTML 解析前几毫秒运行，且不执行 JS、不读 CSS。一旦错过，就得等 DOM 构建完成再触发 <img> 的自然加载，晚 200–600ms 是常态。
-
<link rel="preload" href="hero.webp" as="image">必须写在里，且href路径必须和最终<img src>完全一致（包括大小写、斜杠、查询参数） - 如果图片通过
<picture></picture>提供 WebP/AVIF 回退，preload只能指定一种格式；建议优先预加载 WebP（兼容性更稳），避免因格式不匹配导致重复下载 - 不要对同一资源既
preload又留着<img src>却没配srcset：Chrome 可能并发请求两次，反而拖慢 LCP
fetchpriority="high" 在 Chrome 中有效，但不能替代 preload
这个属性是 Chrome 101+ 引入的调度提示，作用是让网络请求插队，但它不改变协议层行为，也不被 Safari/Firefox 支持。实测中单独加 fetchpriority="high" 对 LCP 改善有限（平均仅提前 30–80ms），而搭配 preload 才有叠加效果。
- 正确用法：
<link rel="preload" href="hero.webp" as="image" fetchpriority="high">——preload确保早发请求，fetchpriority确保高优调度 - 错误用法：
<img src="hero.webp" fetchpriority="high">却没preload：请求仍受 HTML 解析顺序和 CSS/JS 阻塞影响，提升不明显 - 注意：若页面已用 SSR/SSG 输出带
src的<img>，再加preload会触发双请求，需配合 HTTP 缓存策略（如Cache-Control: immutable）避免浪费带宽
字体预加载对文本类 LCP 的影响常被低估
当 LCP 是 <h1></h1> 或首段正文时，实际瓶颈常不在 HTML 或图片，而在字体加载。浏览器默认会等关键字体就绪才绘制文字（FOIT），这会让 LCP 时间直接卡在字体响应之后。
- 必须用：
<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>——crossorigin属性不可省，否则字体加载会被 CORS 阻断 - 配套设置
@font-face { font-display: swap; }，确保文字先用系统字体渲染，再平滑替换，避免白屏等待 - 实测数据：某电商首页主标题为 LCP 元素，未预加载字体时 LCP 中位数 3.8s；加入字体
preload+font-display: swap后降至 1.9s（TTFB 保持 120ms 不变）
为什么预加载后 LCP 没改善？先查这三件事
预加载本身不保证 LCP 下降，它只是把资源拉得更早；如果后续环节卡住，提速就白费。常见断点不在前端代码里，而在服务端或 CDN 配置。
- 检查
preload请求是否真被浏览器发起：打开 Chrome DevTools → Network → 过滤media或font，确认该请求状态码是 200 且时间线早于<img>自然加载 - 确认图片或字体文件是否启用 Brotli 压缩、是否走 CDN 缓存：未压缩的 WebP 图片即使预加载，传输耗时仍可能占 LCP 大头
- 验证 TTFB 是否稳定 ≤ 200ms：若服务器响应慢（比如动态生成 HTML 耗时 400ms），预加载再早也得等 HTML 到达才能开始解析，LCP 底线就被锁死
preload 的收益高度依赖上下文——它解决的是“浏览器知不知道要加载”，而不是“能不能马上加载完”。路径不对、缓存失效、服务端延迟，都会让这一行 HTML 标签变成无效装饰。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
