preload仅用于浏览器发现过晚但首屏必需的资源，如CSS中@font-face字体、内联样式中的首屏图片、module脚本依赖的主chunk及Hero区域关键图片；as属性必须准确匹配资源类型，否则降级为普通请求。
preload 不是“所有关键资源都加一遍”，而是只对浏览器发现太晚、又必须立刻用的资源才生效；加错反而拖慢首屏。
哪些资源真该用 preload
浏览器在解析 HTML 时，只能自动发现 <script src></script>、 这些标签里的资源。但以下几类常被“藏”在 CSS 或 JS 里，直到解析完才被发现，导致 FOIT、FOUC 或首屏图片延迟：
- CSS 中
@font-face引用的字体文件（尤其 WOFF2） - 内联
里用到的、但没在 HTML 中显式声明的首屏图片 URL - 紧随其后的
<script type="module"></script>所依赖的主 chunk（如app.js），而它本身没写src属性 - Hero 区域的
这些才是 preload 的合理作用域。不是“所有 .js 都 preload”，更不是“把 webpack 打包出的 20 个 chunk 全写进去”。
as 属性填错等于白写
as 不是可选装饰，它直接决定浏览器如何发起请求：请求头（Accept）、CSP 校验、缓存分区、甚至是否允许跨域。填错就降级为普通 fetch，失去预加载意义。
-
as="font"→ 必须带crossorigin，否则 Chrome/Safari 直接忽略（即使同源） -
as="style"→ 触发Accept: text/css，且后续能复用该响应；别对rel="stylesheet"的 link 再套一层 preload，可能触发二次解析 -
as="image"→ 支持fetchpriority="high"（Chrome 101+），但不支持srcset或sizes，所以只适合确定尺寸和格式的单图 -
as="script"→ 只下载不执行；若后续仍用<script src></script>引入同一 URL，浏览器会复用；但若脚本含type="module"且有integrity，preload 也得带上该属性，否则缓存不匹配
常见错误现象与验证方式
写了 preload 标签不等于生效。打开 Chrome DevTools → Network 面板，筛选目标资源名，重点看三列：
-
Initiator：应显示preload，不是parser或script；如果是后者，说明浏览器没把它当预加载处理 -
Priority：字体/JS 应为Highest，CSS/图片为High；若显示Low或Medium，大概率是as没写或写错 -
Size和Time：对比未加 preload 时同资源的起始时间，理想应提前 200–600ms；若看到pending或canceled，可能是 HTTP/2 推送已发、或 preconnect 未就绪就发了请求
特别注意 Safari：它对 as="font" 的 crossorigin 更严格，漏写或写成 crossorigin="" 都可能失效；同时 Safari 会忽略 fetchpriority，但不影响 preload 本身。
动态插入 preload 要小心
服务端无法预知的资源（如按用户设备加载高清图、AB 实验脚本），需 JS 动态插入 。但有两个硬约束：
- 必须在
DOMContentLoaded前插入，越早越好；动态插入太晚（比如在load事件后），Chrome 可能直接忽略 - 插入前先检查是否已存在相同
href的preload标签，避免重复创建（尤其是单页应用路由切换时） - 不要用
new Image().src = url替代 —— 它无法监听失败，也不进 HTTP 缓存，更不会被后续
真正容易被忽略的是：preload 只解决“下载时机”，不解决“使用时机”。比如预加载了字体，但 CSS 里没配 font-display: swap，照样 FOIT；预加载了图片，但没在 width/height，懒加载时仍会 CLS。这些必须配套落地，preload 才算闭环。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
