preload 加对了才快，需正确设置as属性、位置及配套属性；prefetch用于下一页资源，二者调度场景不同，用错会拖慢LCP达300ms。
preload 不是“加了就快”，而是“加对了才快”；prefetch 也不是“写了就下”，而是“空闲了才动”。用错一个，LCP 可能拖慢 300ms。
as 属性写错或漏写，preload 就等于没写
浏览器靠 as 决定请求头、CORS 策略、缓存分区和优先级。漏写或类型不匹配，Priority 直接降为 Low，和普通 fetch 无异。
-
as="font"必须配crossorigin，哪怕字体同域——Chrome 120+ 默认启用 CORS 检查，不加则字体下载完也不应用 -
as="style"必须带onload="this.onload=null;this.rel='stylesheet'"，否则只下载不解析 -
as="script"若后续仍用<script src>引同一 URL，能复用；但若有integrity，preload也得带上，否则缓存不匹配 -
as="image"不支持srcset或sizes，只适合确定尺寸/格式的单图；对普通<img src>无效
preload 放错位置，浏览器根本不识别
preload 必须放在 <head> 里且越靠前越好——浏览器解析到就立即发起请求，不等 DOM 构建完成。放错位置，等于白写。
- ✅ 正确位置：紧贴
<meta charset>后、<title></title>前 - ❌ 错误位置：跟在
<link rel="stylesheet">下方，或用document.createElement('link')动态插入 - 放在
<body>里完全无效，浏览器根本不识别
preload 和 prefetch 不是“谁更早”，而是“谁该在哪儿”
两者调度队列不同：preload 请求显示为 High，prefetch 是 Low；但关键不在优先级高低，而在资源归属场景。
立即学习“前端免费学习笔记（深入）”；
-
preload只用于当前导航中「HTML 解析过程中发现太晚」的资源：比如@font-face引用的.woff2、内联<style>里的background-image、<script type="module">后紧跟的主 chunk -
prefetch适合用户行为可预测的下一页资源：比如首页点击「商品列表」后大概率进详情页，才prefetch detail.js - 把本该
prefetch的detail.js写成preload，它会抢占当前页连接和带宽，挤掉critical.css或首屏图片
验证 preload 是否生效，不能只看 HTML 有没有那行
打开 Chrome DevTools → Network 面板，筛选和检查要具体：
- 按
Initiator列筛选preload（不是parser或script） - 检查
Priority列：应为Highest或High；若显示Medium或Low，说明as漏写、写错，或没加crossorigin - 点开请求详情，确认 Response Headers 中有
timing-Allow-Origin（跨域字体必需）
真正容易被忽略的是：preload 不是“加了就快”，而是“加对了才快”。它只绕过 HTML 解析顺序限制，不解决网络 RTT、服务器响应慢或资源体积大这些底层问题。
