rel="preload"仅对浏览器“发现太晚但首屏立刻要用”的资源有效，必须写在<head>中靠前位置、配准as属性并严格匹配类型，否则降级为Low优先级fetch；错用会抢带宽、拖慢首屏甚至白屏。
加了 rel="preload" 不等于资源就变快了——它只对“浏览器本来看不见、但首屏立刻要用”的资源有效，加错位置、漏写 as、类型配错，都会让它降级成普通 fetch，Priority 显示 Low，和没写一样。
preload 必须写在 <head> 里且越靠前越好
浏览器一解析到 <link rel="preload"> 就发起请求，不等 DOM 构建完成。放在 <body> 里、JS 动态插入、或跟在一堆 <link rel="stylesheet"> 后面，基本无效。
- ✅ 正确位置：
<meta charset>后、<title>前 - ❌ 错误写法：
document.createElement('link')插入，或放在<script>标签之后 - ⚠️ 风险：放得太晚，字体或首屏图可能已错过最佳加载窗口，延迟 200ms+ 是常态
as 属性漏写或写错，preload 就白写了
as 不是可选装饰，它直接决定请求头、CORS 策略、缓存分区和优先级。Chrome DevTools Network 面板里如果看到 Priority 是 Low，基本可以断定 as 漏了或类型不匹配。
-
as="font"→ 必须同步加crossorigin（哪怕同源），否则字体加载完也不会应用 -
as="style"→ 必须配onload="this.onload=null;this.rel='stylesheet'"，否则只下载不生效 -
as="script"→ 若后续仍用<script src>引同一 URL，能复用；但若有integrity，preload 也得带上，否则缓存不匹配 -
as="image"→ 不支持srcset或sizes，只适合确定尺寸/格式的单图；对普通<img src>无效，不如直接设fetchpriority="high"
哪些资源真该用 preload，哪些千万别碰
浏览器只能自动发现 <img>、<script src>、<link rel="stylesheet"> 里的资源。以下几类常被“藏”着，等解析完 CSS 或 JS 才暴露，导致 FOIT、FOUC 或首屏图延迟：
立即学习“前端免费学习笔记（深入）”；
- ✅ 该用：
@font-face引用的字体（尤其.woff2）、内联<style>里的background-image、紧跟<script type="module">后的主 chunk、首屏<picture>中关键<source> - ❌ 别碰：
analytics.js、非首屏轮播图、第三方 widget 脚本、懒加载模块——它们不参与首屏渲染，纯属带宽干扰 - ⚠️ 特别注意：不要对
<img src>加 preload，不如直接设fetchpriority="high"更简单有效
怎么验证 preload 真起作用了？不能只看 HTML 有没有那行
打开 Chrome DevTools → Network 面板，筛选条件要具体：
- 按
Initiator列筛选preload（不是parser或script） - 检查
Priority列：应为Highest（as="font"）或High（as="style"），不是Low - 对比未加
rel="preload"时的Time：理想可提前 200–600ms 开始下载，弱网下收益更明显 - 如果看到
Failed to load resource: net::ERR_CONNECTION_REFUSED，说明href路径错误或服务未响应
最容易被忽略的是：preload 不是“越多越好”，而是“只对真正卡首屏的那几个资源才值得加”。加错一个，就可能抢走带宽、拖慢关键路径，甚至引发白屏。实际项目中，建议先用 Lighthouse 的 “Preload Key Requests” 报告定位真正瓶颈，再逐个加，加完立刻验证 Priority 和 Time 变化。
