rel="preload"仅对当前页首屏强依赖且浏览器发现太晚的资源有效，如css中@font-face字体、内联style背景图、模块脚本及关键picture source；必须配准as属性并置于中，否则降级为低优先级fetch。
rel="preload 不是“用了就快”，而是“用错就白用”——它只对明确知道加载时机和依赖关系的资源有效，盲目预加载 CSS、JS 或字体反而会抢占带宽，拖慢首屏。
什么时候该用 rel="preload？看三个硬条件
它不是通用加速开关，只在特定链路中起作用：资源必须被当前 HTML 文档同步需要、浏览器无法自主发现、且你已确认其加载优先级高于默认调度。
- 典型场景：
<link rel="preload">用于提前获取后续 JS 中动态import()的模块、CSS 里@font-face引用的字体、或内联脚本中马上要用的 JSON 数据文件 - 不能替代
rel="stylesheet"或rel="script"：浏览器对它们有内置预扫描（preload scanner），但对@import、fetch()、new Image()等触发的资源不会主动发现 - 关键判断点：打开 Chrome DevTools → Network → Disable cache → 刷新，看目标资源是否出现在“Early hints”之后、但主资源解析完成之前 —— 如果它卡在 JS 执行后才发起，就是
preload的适用位
as 属性填错会导致资源被降级加载
as 不是可选的装饰字段，它直接决定浏览器如何处理预加载资源的优先级、CSP 校验和缓存策略。填错等于告诉浏览器“这个字体当脚本用”，结果就是不渲染、报 CSP 错误或被丢弃。
- 常见配对：
as="font"（配合crossorigin）、as="script"、as="style"、as="image"、as="fetch" - 字体必须加
crossorigin：即使同源，as="font"也会触发 CORS 请求，漏写crossorigin导致字体加载失败且无提示 -
as="fetch"仅适用于type="application/json"等明确 MIME 类型的资源；若后端返回text/plain却声明as="fetch"，Chrome 会拒绝使用预加载缓存
别把 rel="preload" 和 rel="prefetch" 搞混
两者语义完全不同：preload 是“现在就要用”，prefetch 是“将来可能用”。混用不仅浪费带宽，还可能阻塞关键资源。
-
preload资源进入内存缓存，参与渲染阻塞；prefetch进入 HTTP 缓存，不参与当前页面调度 - 例如：某个按钮点击后才加载的图表库，应该用
rel="prefetch"；而页面顶部 banner 图片由内联 JS 动态创建Image实例，才适合rel="preload" - Chrome 94+ 对
preload资源设置了 3s 超时：如果 HTML 解析完 3 秒内没被 JS/CSS 引用，会取消请求并警告 “Preload request for X was canceled”
最常被忽略的是资源实际使用路径和预加载路径不一致——比如预加载了 /assets/logo.svg，但 JS 中实际请求的是 /img/logo.svg（路径差一个目录），浏览器根本不会复用，只会多发一次请求。验证方式很简单：Network 面板里右键 preload 条目 → “Reveal in Network” → 看 Initiator 是否指向你预期的 JS 行号或 CSS 规则。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
