rel="preload"用于让浏览器在html解析早期预加载关键资源，不阻塞渲染；仅当资源发现过晚导致明显延迟时才应使用，如首屏图片、关键字体、核心js等，且必须正确设置as属性并置于初始html的中。

rel="preload 的作用很直接：让浏览器在解析 HTML 的早期阶段就发起关键资源的请求，不阻塞渲染，也不执行，只“先拉下来存着”，等真正用到时立刻可用。

什么时候该用 rel="preload？

只在资源被发现得太晚、导致明显延迟时才值得加。比如：

• 首屏 hero 图片在 <img> 标签里才出现，但浏览器直到解析到那个位置才开始请求 → 提前在 里 <link rel="preload" href="/hero.jpg" as="image">
• 关键字体（如 font.woff2）由 CSS @font-face 加载，而 CSS 文件本身又延迟加载 → 把字体单独 preload，并带上 crossorigin
• 核心 JS（如框架入口或首屏逻辑）被 <script src="app.js"></script> 同步引入，但 HTML 文档较大 → 改用 <link rel="preload" href="app.js" as="script">，再配合动态 import() 或插入 <script></script> 控制执行时机

as 属性填错会怎样？

填错 as 不只是语义问题，而是直接影响浏览器行为：

Article To Html

文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。

下载

• as="script" → 浏览器发请求时带 Accept: application/javascript，走 script 的优先级队列和缓存策略
• as="font" → 必须配 crossorigin，否则字体加载失败（Chrome 会静默丢弃）
• as="style" → 可配合 onload 事件切换成 rel="stylesheet"，实现“下载完再应用”
• 漏写 as 或写成 as="fetch" → 降级为普通 fetch() 请求，失去类型感知，无法正确设置请求头、CSP 匹配失败、缓存可能错乱

为什么 rel="preload" 有时没效果？

常见失效原因不是语法错，而是使用逻辑偏差：

• 预加载了用户根本不会触发的资源（比如某个弹窗里的 SVG 图标），白占带宽和 HTTP/2 流
• 在动态插入的 HTML 片段里写 <link rel="preload"> → Chrome 会忽略，必须出现在初始 HTML 的 中
• 把 preload 和 prefetch 混用：后者是为“下个页面”准备的，浏览器只在空闲时加载；前者是为“当前页面”抢时间，填错就彻底跑偏
• 没确认资源是否真有“加载-使用”的时间差：如果 JS 在 末尾同步加载，且体积小、CDN 响应快，preload 反而增加解析开销

真正难的不是怎么写这行标签，而是判断“这个资源到底算不算关键”——它依赖对页面加载流水线、网络条件、用户行为路径的具体理解，而不是套模板。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！