preload生效必须priority为highest，否则因as属性漏写/错写、未配crossorigin或位置靠后导致降级；仅限当前导航关键资源，错用会挤占带宽。
Preload加了但没提速？先看Network面板里Priority是不是Highest
很多开发者写了<link rel="preload">就以为完事，结果Lighthouse分数没变、首屏时间也没降——根本原因是浏览器压根没把它当高优处理。打开Chrome DevTools → Network面板，筛选Initiator列等于preload的请求，再盯住Priority列：必须是Highest才算生效；如果显示High或Low，说明as漏写、写错，或者位置太靠后。
常见错误现象：
-
as="font"没配crossorigin→ Priority降为Low，字体下载完也不渲染 -
as="style"没写onload="this.rel='stylesheet'"→ 只下载不应用，样式延迟生效 -
<link>放在<title></title>之后或<link rel="stylesheet">下方 → 解析到时关键资源已错过最佳加载窗口，延迟200ms起
as属性写错等于没写，不是可选装饰而是强制类型声明
as不是告诉浏览器“这大概是个字体”，而是直接决定请求头、CORS策略、缓存分区和优先级调度。写错或漏掉，浏览器就按普通fetch处理，Priority自动归为Low。
必须严格匹配的场景：
-
as="font"→ 必须同步加crossorigin（哪怕同源），否则Chrome拒绝应用 -
as="style"→ 后续<link rel="stylesheet">才能复用该预加载结果；写成as="fetch"或不写，缓存不命中 -
as="script"→ 若后续<script src></script>引用同一URL，且带integrity，preload也得带上相同integrity，否则缓存不匹配 -
as="image"→ 不支持srcset或sizes，只适合确定尺寸/格式的单图；对普通<img src>无效
哪些资源真该Preload，哪些加了反而拖慢首屏
Preload不是“越多越好”，它是高优先级指令，写错会抢带宽、挤掉HTML或关键CSS本身。只对当前导航中「马上就要用」的资源生效。
✅ 该用：
- @font-face引用的
.woff2字体（尤其首屏文本依赖的） - 内联
<style></style>里用到的background-image（浏览器无法自动发现） - 紧跟
<script type="module"></script>后的主chunk（解析JS前就该在缓存里） - 首屏
<picture></picture>中明确的关键<source></source>（如media="(min-width: 768px)"匹配的那张）
❌ 别碰：
-
<img src>→ 不如直接设fetchpriority="high"或loading="eager" - 非首屏轮播图、懒加载模块、第三方widget脚本 → 它们不参与首屏渲染，纯属带宽干扰
- analytics.js、埋点SDK → 它们不需要「立刻可用」，prefetch更合适
验证Preload是否起效，不能只看HTML有没有那行
真正有效的验证方式只有两个：Network面板里看Initiator和Priority，以及实际测量FOIT/FOUT是否消失、LCP是否提前。别信“我写了就一定生效”这种直觉。
容易被忽略的复杂点：
- 字体预加载必须配合
font-display: swap或optional，否则即使预加载完成，浏览器仍阻塞文本渲染（FOIT） - Webpack/Vite等构建工具自动注入的preload，可能把非首屏chunk也加进去，需检查生成的HTML是否精准匹配路由
- 服务端渲染（SSR）页面中，preload路径若含动态参数（如
/fonts/${locale}.woff2），必须确保服务端能正确拼出绝对URL，否则404
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
