rel="preload"仅适用于当前页首屏立即使用的资源，如字体、内联样式中的背景图、模块脚本入口及关键图片源；误用于懒加载脚本、动态import或第三方分析脚本会拖慢性能。
rel="preload" 只对“当前页首屏立刻要用”的资源有效，用错场景反而拖慢首屏；它不是通用加速开关，而是精准狙击关键路径的加载时机工具。
哪些资源真该用 rel="preload"
浏览器在 HTML 解析早期就能发现 <img src>、<link rel="stylesheet"> 这类资源，但以下几类常被“藏”着，等 CSS 或 JS 解析完才暴露，导致 FOIT、FOUC 或首屏图延迟：
- @font-face 引用的 WOFF2 字体 → 必须
as="font"+crossorigin（同源也要加） - 内联
<style>里用到的background-imageURL → 需手动提取并 preload - 紧跟
<script type="module">的主入口脚本（如app.js）→ 必须as="script"，且放在<head>最前 - 首屏
<picture>中确定尺寸/格式的关键<source>→ 用as="image"，不支持srcset
哪些场景绝对不能用 rel="preload"
强行给不该预加载的资源加 rel="preload"，会抢占带宽、触发重复请求、甚至被浏览器主动 cancel：
- 动态 import() 产生的 chunk（如
import('./settings.js')）→ 浏览器无法静态识别路径，preload 无效，写了也白写 - 路由级懒加载脚本（如 product-detail.js）→ 它不属于当前页关键路径，该用
rel="prefetch"而非 preload - 第三方分析脚本（如 analytics.js）→ 不参与首屏渲染，纯属干扰
- 普通
<img src>→ 不如直接设fetchpriority="high"简单有效
为什么 preload 写在 HTML 里却没生效
常见失效不是代码写错，而是位置或参数没卡准：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- 没放在
<head>最前：必须紧贴<meta charset>后、<title>前；塞在<link rel="stylesheet">下面就晚了 200ms+ -
as属性漏写或写错：字体漏crossorigin、CSS 没配onload切换rel、JS 漏as="script"→ 全部退化为 Low 优先级 fetch - 路径不一致：preload 的
href和后续<script src>或import()的路径必须完全相同（包括查询参数、hash），否则缓存不复用 - 服务端 MIME 错误：字体返回
text/plain、JS 返回text/javascript→ Safari/Edge 拒绝执行
验证 preload 是否真起作用
不能只看 HTML 有没有那行，得看浏览器实际行为：
- Chrome DevTools → Network 面板 → 筛选
Initiator: preload，Priority 应为Highest（不是Low或(Other)） - 对比时间线：preload 请求应出现在 HTML 解析阶段，早于所有
<script>和<link rel="stylesheet"> - 清缓存后刷新，再检查目标资源是否从 “from memory cache” 加载（说明复用成功）
- 若用了
integrity，确保 preload 标签也带相同值，否则即使路径对，也会重新下载
最容易被忽略的是：preload 不是“提前下载就完事”，它和后续使用方式强绑定——字体要配 crossorigin 才能应用，CSS 要靠 onload 切换 rel 才能生效，JS 要路径+integrity+MIME 全匹配才能复用。少一个环节，前面全白干。
