preload必须放在内且越靠前越好，紧贴后或前；需同时指定正确href和as属性（如as="font"须配crossorigin），否则无效；仅用于当前导航必需资源，不可用于非首屏或懒加载资源。
preload 该加在哪个位置才生效
必须放在 内，且越靠前越好——浏览器解析到它就会立刻发起请求，不等 DOM 构建完成。放在 或 JS 动态插入的 <link> 都无效，因为 preload 是 parser-blocking 阶段的行为。
常见错误是把它塞在 CSS 或 JS 引入之后，结果关键字体或首屏图片加载被延迟了 200ms+。
- ✅ 正确：紧贴
<meta charset>后面，或<title></title>前 - ❌ 错误：放在
<link rel="stylesheet">下方，或用document.createElement('link')插入 - ⚠️ 注意：
preload不会阻塞渲染，但会提升资源优先级，可能挤占其他资源带宽
href 和 as 属性必须同时存在且匹配
as 告诉浏览器“这个资源是什么类型”，直接影响请求头（如 Accept）、CSP 策略、缓存策略和优先级调度。漏写或写错 as，浏览器就当普通 <link> 处理，不会提前加载。
典型错误：给字体写成 as="font" 却没加 crossorigin，导致字体加载失败（浏览器强制要求 CORS）。
- 字体必须用
as="font"+crossorigin（即使同源） - CSS 用
as="style"，JS 用as="script"，关键图片用as="image" -
href路径必须可访问，404 时浏览器仍会发请求，但不会触发 error 事件，容易被忽略
preload 不等于 prefetch，别用错场景
preload 是“我马上就要用这个资源”，prefetch 是“我稍后可能用”。混用会导致资源加载时机错乱：比如对非首屏懒加载模块用 preload，反而抢占首屏带宽，LCP 变差。
真实项目中，90% 的误用发生在把路由级 JS chunk 当作关键资源预加载。
- ✅ 适合
preload：首屏 Hero 图、WebFont、核心 CSS、内联关键 JS 依赖的模块 - ❌ 不适合
preload：tab 切换后才显示的组件、用户交互后才加载的数据接口、第三方统计脚本 - ? 检查方法：用 Chrome DevTools 的 Network → Priority 列，确认资源是否标记为
Highest
兼容性与 fallback 方案怎么处理
IE 完全不支持 preload，Safari 直到 11.1 才支持 as="font"，旧版安卓 WebView 有解析 bug。不能只靠它保首屏性能。
最稳妥的做法是：preload 作为增强，原有加载逻辑（如 CSS 中的 @font-face、<img> 标签）必须保留且能独立工作。
- 字体：仍需在 CSS 中声明
@font-face，preload只是加速首次渲染 - 图片：
<img src>不能删，preload仅用于提前解码（配合fetchpriority="high"更好） - JS：若用
preload加载模块，后续仍需import()或new Promise接入执行流程
真正难的是判断“哪些才算关键”——往往不是体积最大的资源，而是阻塞首次绘制的那个。这点容易被 Lighthouse 报告带偏。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
