只有当资源被浏览器发现过晚导致首屏卡顿或FOIT/FOUT时才应使用rel="preload"，如首屏图、自定义字体、关键CSS；需严格匹配as属性（如as="style"、as="font"必加crossorigin），避免误用于懒加载资源、第三方API或非关键资源。
什么时候该加 rel="preload"
只有当某个资源被浏览器发现得太晚、导致首屏渲染卡顿或文字闪动（FOIT/FOUT）时，才值得加 rel="preload"。比如：首屏 banner 图还没下载完就尝试渲染、自定义字体加载滞后、关键 CSS 解析被阻塞。它不是“所有重要资源都来一遍”的保险策略——加错反而抢占带宽，拖慢真正需要的资源。
as 属性必须写对，否则等于没写
浏览器靠 as 判断资源类型，从而设置正确的请求头、CSP 策略和缓存行为。填错或漏掉，资源可能被降级为普通 fetch 请求，甚至被忽略。
-
as="style"→ 用于 CSS 文件，触发Accept: text/css；不要对stylesheet用as="script" -
as="script"→ 用于 JS 文件，进 script cache；但后续仍需<script src></script>才会执行 -
as="font"→ 字体必须同时加crossorigin，哪怕同域；否则浏览器直接跳过预加载 -
as="image"→ 支持fetchpriority="high"（Chrome 109+），对首屏大图有效 - 不支持
as="video"或as="audio"的自动预加载逻辑，实际效果不稳定，慎用
常见误用场景和对应解法
很多问题不是标签不会写，而是用错了时机或对象。
- 把路由懒加载的 JS 用
rel="preload"—— 改用rel="prefetch"，让浏览器空闲时拉取 - 给
loading="lazy"的图片加preload—— 懒加载本意就是推迟，两者逻辑冲突 - 在动态插入的 HTML 片段里写
preload—— Chrome 可能忽略，只认静态中的声明 - 对第三方 API 接口地址写
href="https://api.example.com/data.json"—— 这是preconnect的事，不是preload的职责 - HTTP/2 推送已启用时还硬加
preload—— DevTools Network 面板里会出现 pending/canceled，说明重复触发
验证是否真生效，别只看代码写了没
打开 Chrome DevTools → Network 面板，筛选目标资源名，重点看三列：
立即学习“前端免费学习笔记（深入）”；
-
Initiator应显示preload，不是parser或script -
Priority应为Highest或High（字体和首屏图通常是 Highest） -
Time对比未加前：理想可减少 200–600ms，尤其在弱网或高延迟 DNS 场景下 - 如果看到
net::ERR_CONNECTION_REFUSED，先检查href路径是否拼错、服务是否响应
真正容易被忽略的是：as 值和资源实际 MIME 类型不匹配时，浏览器不会报错，但请求头错误、缓存复用失败——这种失效是静默的，只能靠 Network 面板里的 Headers 标签页逐个核对 Accept 和 Content-Type。
