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