rel="preload"是当前页关键资源提速的唯一可靠手段，但必须写在<head>中<meta charset>后<title>前、as属性精准匹配类型（如as="font"需crossorigin、as="style"需onload转rel）、路径完全一致，否则降级为Low优先级fetch且无效。
直接说结论：rel="preload" 是当前页关键资源提速的唯一可靠手段，但加错位置、写错 as、路径不一致，它就等于没写。
rel="preload" 必须写在 最前面，动态插入完全无效
浏览器只在 HTML parser 阶段识别 rel="preload"，一旦开始构建 DOM 或进入
document.createElement('link')）根本不会触发预加载。
-
✅ 正确位置：
<meta charset="utf-8">后、<title>前 -
❌ 错误位置：放在
<link rel="stylesheet">下方、<body>里、或任何 JS 脚本块之后 - 多个
preload按书写顺序发起请求，但优先级由as决定，不是靠“抢位置”
as 属性写错 = 白写，且不报错、不警告
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 开始下载，弱网下收益更明显 - 如果看到
net::ERR_CONNECTION_REFUSED，说明href路径错误或服务未响应；如果 Priority 是 Low，基本可以断定as漏了或写错了
最容易被忽略的一点：preload 对跨页面无效，它只服务于当前页生命周期；想预加载下一页资源，必须换用 rel="prefetch"，且得满足 onload 完成、浏览器空闲、同源三硬条件——否则写了也白写。
