rel="preload"是当前页关键资源提速的唯一可靠手段，必须静态写在<head>中<meta charset>后、<title>前，as属性精准匹配类型且路径完全一致，否则降级为Low优先级fetch，静默失效。
rel="preload" 是当前页关键资源提速的唯一可靠手段，但它必须写在 <head> 中 <meta charset> 后、<title> 前，且 as 属性精准匹配类型、路径完全一致，否则就等于没写。
preload 必须静态写在 head 最前面，动态插入完全无效
浏览器只在 HTML parser 初期识别 rel="preload"，一旦开始构建 DOM 或遇到 <body>，后续的 <link rel="preload"> 就被忽略。JS 动态创建（比如 document.createElement('link')）根本不会触发预加载。
- ✅ 正确位置：
<meta charset="utf-8">紧跟其后，或<title>前 - ❌ 错误位置：放在
<link rel="stylesheet">下方、<body>里、任何<script>标签之后 - ⚠️ 多个
preload按书写顺序发起请求，但优先级由as决定，不是靠“抢位置”
as 属性漏写或写错，preload 就静默失效
as 不是可选提示，它强制决定请求头、CORS 策略、缓存分区和 Network 中的 Priority。漏写或填错，rel="preload" 就降级为普通 fetch，Priority 显示 Low，Initiator 可能是 (Other)。
- CSS 文件 → 必须
as="style"（不是"stylesheet"） - 字体（
.woff2/.woff）→as="font"+crossorigin（同源也必须加） - JS 脚本 →
as="script"（模块脚本也用这个，不用配type="module"） - 图片 →
as="image"（as="img"或as="picture"全部无效） - JSON 接口 →
as="fetch"，且响应头需含Access-Control-Allow-Origin
preload 只下载，不执行；CSS 和字体要额外处理
<link rel="preload" href="main.css" as="style"> 只负责下载，不会解析、不会应用。如果再写一个 <link rel="stylesheet" href="main.css">，路径稍有差异（比如斜杠、大小写、查询参数），就会触发二次请求。
立即学习“前端免费学习笔记（深入）”；
- CSS 正确做法：
<link rel="preload" href="main.css" as="style">+<link rel="stylesheet" href="main.css">，两处href字符串必须完全一致 - 字体正确做法：
<link rel="preload" href="/fonts/inter.woff2" as="font" crossorigin>，配合 CSS 中@font-face使用，且建议加font-display: swap - 不要对
<img src>或srcset图片用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路径错误或服务未响应；如果Priority是Low，基本可以断定as漏了或写错了
最容易被忽略的是路径一致性——哪怕多一个尾部斜杠、大小写不一致、查询参数顺序不同，都会导致缓存不复用，变成两次请求。这不是浏览器 bug，而是设计如此。
