rel="preload"仅对本页立即渲染所需的资源生效，需严格匹配as和crossorigin属性；误用会抢占带宽、拖慢首屏。
link 标签的 rel="preload" 不是“写了就快”，用错反而拖慢首屏——它只对「当前导航立刻要用」的资源生效，且必须配对正确的 as 和 crossorigin。
什么时候该用 rel="preload"，而不是 rel="prefetch" 或 rel="preconnect"
三者语义和调度优先级完全不同，混用等于白写：
-
preload：浏览器高优先级下载，用于「本页马上渲染就要用」的资源（比如首屏字体、Hero 图、关键 CSS 中引用的 font-face） -
prefetch：低优先级后台加载，适用于「用户下一步可能访问的页面资源」（如点击后跳转页的 JS chunk），不保证执行时机 -
preconnect：仅建立跨域连接（DNS + TCP + TLS），不下载任何内容，适合 CDN 域名、第三方 API 域（如https://fonts.googleapis.com）
常见错误：把 main.js 写成 preload —— 它本身已被 defer 或 module 控制加载时机，再 preload 会抢占带宽，挤掉 HTML 或关键 CSS 的下载。
as 和 crossorigin 必须同时配对，否则资源不生效
浏览器靠 as 判断资源类型，从而分配正确优先级和解析逻辑；而 crossorigin 决定是否能读取响应体（尤其对 font 和 script）：
立即学习“前端免费学习笔记（深入）”；
- 预加载字体：
<link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin="anonymous">—— 缺crossorigin，字体不会应用，控制台报 CORS 错误 - 预加载图片：
<link rel="preload" href="/hero.webp" as="image">—— 无需crossorigin，但必须有as="image"，否则当普通 link 处理，失去高优先级 - 预加载脚本：
<link rel="preload" href="/vendor.js" as="script" crossorigin="anonymous">—— 若脚本来自同域，可省略crossorigin；跨域必须加，否则 fetch 失败
别在 CSS 里用 @import，也别用 preload 补救
@import 是串行阻塞式加载，实测拖慢 FCP 超 300ms。更糟的是，有人试图用 preload 提前拉 @import 的 CSS 文件——这毫无意义：
- 浏览器仍要等主 CSS 解析到
@import行才发起请求，preload无法绕过该解析时机 - 若预加载的 CSS 本身又含
@import，问题层层嵌套，白屏风险翻倍 - 正确做法：把所有关键样式内联进
<style></style>，非关键 CSS 用media="print" onload="this.media='all'"延迟加载
preload 验证是否真正起效，只看 Chrome Network 面板的 Priority 列
光看资源是否出现在 Network 列表里没用，关键看调度优先级是否为 high：
- 打开 DevTools → Network → 刷新页面 → 找到预加载资源 → 检查
Priority列是否显示High - 若显示
Low或Medium，说明as值错误（比如漏写as="font"导致被当成fetch类型）、或路径 404、或服务器返回了no-cache等干扰头 - 注意：
preload资源不会在 Elements 面板中自动插入 DOM，它只是提前下载进内存/HTTP 缓存，后续由 CSS 或 JS 主动使用
最容易被忽略的一点：预加载资源必须被页面实际消费。如果 preload 了一个字体，但 CSS 里没用 @font-face 引用它，或者引用的 font-family 名不一致，这个预加载就完全浪费了带宽和解析开销。
