preload用于立即加载当前导航关键资源（如字体、首屏css、动态import的js），必须带as和crossorigin属性，否则失效；prefetch仅在空闲时低优先级预取后续页面资源（如下一页js），不保证执行且不可替代首屏优化。
preload 用错会直接拖慢首屏，prefetch 加再多也救不了白屏——关键不在“加不加”，而在“当前导航里它到底算不算刚需”。
什么时候该用 preload 而不是 prefetch
浏览器看到 <link rel="preload"> 就立刻发 high 优先级请求，不管 HTML 解析到哪；<link rel="prefetch"> 则是 low 优先级，等空闲时才下。两者根本不在一个调度队列里。
- 必须用
preload的场景：字体（as="font"）、首屏 CSS（as="style"）、JS 动态 import 的模块（as="script"）——这些资源在 HTML 解析后期才被发现，但渲染又等不及 - 适合
prefetch的场景：用户大概率点击后才会进入的页面资源，比如首页上「商品列表」按钮旁 prefetchdetail.js，而不是把它 preload 到当前页 - 常见错误：把
comments.js（下一页才用）写成 preload → 它抢走连接池，挤掉critical.css或首屏图片，FCP 延迟 300ms+ 是常态
preload 必须带 as 和 crossorigin 才生效
漏写 as，浏览器可能当成普通 GET 请求，降级处理；漏写 crossorigin，字体类资源直接失败，控制台报 CORS 错误，且不会 fallback。
- 字体：必须
<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin> - CSS：用
as="style"，否则可能不参与 CSSOM 构建加速 - JS：仅限动态 import 场景（如
import('./module.js')），不要对main.js这类入口文件重复 preload ——defer已覆盖，再 preload 属于冗余调度 - 验证方式：Chrome DevTools → Network 面板 → 查看 Priority 列，
preload必须是high，否则配置无效
prefetch 不是“提前加载所有下一页资源”的保险丝
它只在浏览器空闲时触发，且不保证缓存命中或执行时机。如果用户没点进去，prefetch 的资源就白下了，还占了 HTTP/2 流和磁盘缓存。
- 适合 prefetch 的资源要满足两个条件：路径可预测（如首页 → 列表页 → 详情页）、资源体积可控（建议 ≤ 100KB JS 或单张 WebP 图）
- 别 prefetch 整个详情页 HTML —— 浏览器不会预解析它，只会缓存 raw bytes，后续仍需完整导航流程
- 服务端渲染（SSR）场景下，prefetch 对 JSON API 无意义，浏览器不支持
rel="prefetch"forfetch()请求 - 注意兼容性：
prefetch在 Safari 15.6+、Firefox 90+、Chrome 61+ 支持；旧版安卓 WebView 可能完全忽略
最容易被忽略的点是：preload 和 prefetch 都无法绕过关键渲染路径本身。如果 HTML 里还藏着 @import、同步 script 或没内联的首屏 CSS，再精准的 preload 也只是给一辆没油的车装涡轮增压。先砍掉阻塞源，再谈资源调度。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
