rel="preload"仅在中且紧随后、资源确为“浏览器发现太晚但首屏立刻要用”时生效；必须配对正确as值（如as="font"需crossorigin、as="style"需onload切换），否则降级为低优先级fetch。
rel="preload" 不是加了就生效，它只在特定位置、配对正确 as 值、且资源确实“浏览器发现太晚但首屏立刻要用”时才起作用。错放、漏写 as、路径不一致，等于白加。
preload 必须放在 里且紧靠 之后
浏览器只在解析
初期读取rel="preload"，如果它出现在 <title></title> 之前、或 <link rel="stylesheet"> 之后，很可能被忽略或失效。
-
<meta charset="utf-8">必须是 中第一个标签（或紧随<title></title>后），否则编码重解析会连带让 preload 失效 - 把
<link rel="preload">放在<meta charset>和<title></title>之后、所有样式表和脚本标签之前——越早声明，越早发起请求 - 用 JS 动态插入（如
document.head.appendChild()）完全无效，它不参与初始 HTML 解析流
as 属性漏写或写错，preload 就退化成普通 fetch
as 不是可选装饰，它直接决定请求头、CORS 策略、缓存分区和优先级。漏写或写错，Priority 列会显示 Low，和没写一样。
-
as="font"→ 必须同步加crossorigin，否则 Chrome/Safari 加载完也丢弃（即使同源） -
as="style"→ 必须配onload="this.onload=null;this.rel='stylesheet'"，否则只下载不生效 -
as="script"→ 若原<script src></script>有integrity，preload 也得带上，否则缓存不匹配；URL 必须完全一致（含查询参数） -
as="image"→ 不支持srcset或sizes，只适合确定尺寸/格式的单图；对普通<img src>无效，不如直接设fetchpriority="high"
哪些资源真该 preload，哪些纯属浪费带宽
preload 的价值在于“浏览器发现太晚但首屏立刻要用”。已通过 <script src></script> 或 <link rel="stylesheet"> 显式声明的资源，浏览器在 HTML 解析阶段就能发现，无需 preload。
- 值得 preload 的：CSS 中
@font-face引用的字体（尤其.woff2）、内联<style></style>里的background-image、紧跟<script type="module"></script>后面的主 chunk、首屏<picture></picture>中关键<source></source> - 不该 preload 的：
analytics.js、非首屏轮播图、第三方 widget 脚本、prefetch场景资源（如下一页面 JS）——它们不参与首屏渲染，纯属带宽干扰 - 对
<link rel="stylesheet">重复 preload 是危险操作：顺序颠倒（先 stylesheet 后 preload）会导致两个独立请求，重复下载
怎么验证 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 只管下载，不管执行或应用时机；它也不解决服务端 Range 支持缺失、moov box 位置不当等底层问题——这些必须单独处理，否则前端加再多 preload 也卡在首帧。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
