preload 是当前页紧急加载，需指定 as 和 crossorigin；prefetch 是后台低优先级预加载，仅适用于后续页面资源，误用会导致首屏延迟。
preload 和 prefetch 看似都是“提前加载”，但浏览器对待它们的方式天差地别：一个是“现在就要，立刻执行”，另一个是“等会儿再说，可能不用”。用错一个，首屏就卡，带宽就被浪费。
rel="preload" 是当前页的“紧急调度员”
它强制浏览器在 HTML 解析早期（甚至早于 CSS/JS）发起请求，目标是当前页面马上要用的关键资源。不带 as 属性，多数现代浏览器直接忽略该 preload；漏掉 crossorigin 加载跨域字体则静默失败。
-
as必须指定，且要准确：比如as="font"、as="script"、as="style"，否则无法正确设置优先级和 CORS 行为 - 字体必须加
crossorigin，否则即使下载成功也不会被 CSS 使用 - 只对当前页有效，跳转后预加载终止，缓存也不跨页复用
- 会抢占带宽——如果给非关键图加
preload，反而拖慢main.css或hero.jpg
rel="prefetch" 是后台的“低优先级备货员”
它不参与当前页渲染调度，只在 load 事件之后、CPU/网络空闲时才尝试发起请求，且随时可能被浏览器取消（节电模式、2G 网络、内存紧张时常见）。
- 无需
as属性也能工作，但加上更稳妥（如as="script"），尤其对非 JS 资源（如 HTML 页面）可避免 MIME 类型误判 - 不能用于字体：prefetch 不触发 CORS 预检，跨域字体大概率静默失败
- 路径必须是绝对或根相对（如
/js/next-chunk.js），子路径下解析易出错 - 资源进入 HTTP 缓存，后续页面可复用——这才是跨页预加载的正解
常见错误：把 prefetch 当 preload 用
典型表现是首页写了一堆 rel="prefetch" 加载 banner 字体、首屏 CSS，结果 LCP 延迟 800ms。因为 prefetch 在 onload 后才开始，而首屏渲染早就等着这些资源了。
立即学习“前端免费学习笔记（深入）”；
- 首屏字体、关键 JS、内联背景图 → 只能用
preload，且as+crossorigin一步不能少 - 点击后才加载的模块、下一页的 JS bundle、搜索页静态资源 → 才适合
prefetch - 同一资源既
preload又prefetch？浏览器会冲突，可能重复请求或相互降级
别碰 rel="noopener" 和 rel="noreferrer" 在 link 上
这两个值对 link 标签完全无效，浏览器直接忽略。它们只在 a 或 form 的 target="_blank" 场景下起作用。写在 link 里纯属白费 HTML 字节。
真正容易被忽略的不是语法，而是时机判断：preload 的资源必须在当前页 DOM 构建或样式计算前就“到位”；prefetch 的资源，你得确认用户真有较大概率点进去——否则就是白下。
