rel="preload"仅对浏览器发现太晚但首屏立即需用的资源有效，必须置于后前、配准as属性（如as="font"需crossorigin）、且资源确在首屏渲染链中，否则降级为低优fetch。
rel="preload" 不是加了就快，而是加对了才快——它只对浏览器“发现太晚但首屏立刻要用”的资源有效。错用会抢带宽、拖慢首屏，甚至白屏。
rel="preload" 必须写在最前面，且不能动态插入
浏览器只在 HTML parser 阶段识别 rel="preload"，一旦进入 DOM 构建或 JS 执行阶段，再插入的 <link rel="preload"> 就被忽略（Initiator 显示为 (Other)，Priority 恒为 Low）。
常见错误包括：
- 把它放在
<link rel="stylesheet">或<script></script>标签之后 - 用
document.createElement('link')+appendChild动态添加 - 塞进
里，哪怕只是测试用
✅ 正确位置：紧贴 <meta charset> 后，或 <title></title> 前；必须出现在初始 HTML 中，不能由服务端模板拼接失败、也不能被构建工具误删。
as 属性漏写或写错，等于没写
as 不是可选装饰，它直接决定请求头、CORS 策略、缓存分区和网络优先级。漏写或写错，rel="preload" 就退化成普通 fetch() 请求。
典型匹配关系：
-
as="font"→ 必须同步加crossorigin，否则 Chrome/Safari 加载完也静默丢弃（即使同源） -
as="style"→ 必须配onload="this.onload=null;this.rel='stylesheet'"，否则只下载不生效 -
as="script"→ 若后续仍用<script src></script>引同一 URL，能复用；但若有integrity，preload 也得带上完全相同的值，否则缓存不匹配 -
as="image"→ 不支持srcset或sizes，只适合确定尺寸/格式的单图；对普通<img src>无效，不如直接设fetchpriority="high"
⚠️ 写成 as="img" 或 as="picture" 完全无效；as="fetch" 仅适用于带 CORS 的 API 数据请求，不是通用兜底项。
哪些资源真该用 rel="preload"？
浏览器只能自动发现 <img>、<script src></script>、<link rel="stylesheet"> 里的资源。以下几类常被“藏”着，等解析完 CSS 或 JS 才暴露，导致 FOIT、FOUC 或首屏图延迟：
- CSS 中
@font-face引用的字体（尤其.woff2），不预加载就等解析完 CSS 才发起请求 - 内联
<style></style>里用background-image加载的 Hero 图，parser 根本看不到 URL - 紧跟在
<script type="module"></script>后面、但没显式src的主 chunk（如app.js），模块执行前必须就位 - 首屏
<picture></picture>中关键<source></source>对应的 WebP/JPEG，srcset是运行时解析的
❌ 别对 analytics.js、非首屏轮播图、第三方 widget 脚本用 rel="preload"——它们不参与首屏渲染，纯属带宽干扰。
怎么验证 rel="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 漏了或写错了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
