预加载需精准配置才有效：必须紧贴<meta charset>后、正确设置as属性及配套参数，并确保资源在当前页面真实使用，否则将静默失效。
预加载不是加了就快，而是加对位置、配对类型、接入流程，才真正抢出那 200ms。 大多数人把 <link rel="preload"> 往 <head> 里一塞就以为完事——结果 Network 面板里 Priority 显示为 Low，字体闪、首屏图延迟、控制台还报 “preload request was not used”，全是结构和配置错位导致的静默失效。
preload 必须紧贴 <meta charset> 后，且不能动态插入
浏览器只在初始 HTML 解析阶段读取 preload 指令，一旦解析流过了 <head> 就不再识别。放在 <title> 后、<link rel="stylesheet"> 前是安全窗口；放到 <body> 或用 document.createElement('link') 插入，等于没写。
-
<meta charset="utf-8">必须是<head>中第一个标签（或紧随其后），否则编码识别延迟会触发重解析，连带让 preload 失效 - 如果构建工具生成的 HTML 把
<title>放在<meta charset>前，preload 就大概率被跳过 - Webpack/Vite 的 html-webpack-plugin 或 vite-plugin-html 默认顺序通常合规，但自定义模板时需人工校验
as 属性漏写或写错，preload 就退化成普通 fetch
as 不是可选装饰，它直接决定请求头、CORS 策略、缓存分区和优先级。Chrome DevTools 的 Priority 列显示为 Low，八成是这里错了。
-
as="font"→ 必须同步加crossorigin（哪怕同源），否则字体下载完也不会应用，控制台可能静默忽略或报Failed to decode downloaded font -
as="style"→ 必须配onload="this.onload=null;this.rel='stylesheet'"，否则只下载不生效，CSSOM 不构建 -
as="script"→ 若后续仍用<script src>引同一 URL，能复用；但若有integrity，preload 也得带上，否则缓存不匹配 -
as="image"→ 不支持srcset或sizes，只适合确定尺寸/格式的单图；对普通<img src>无效，不如直接用fetchpriority="high"
preload 的资源必须在当前导航中真实使用，否则被浏览器标记为“未使用”
它不是预热缓存的通用手段，而是告诉浏览器：“这个资源，我现在就要画第一帧。”没接入渲染流程，就是白忙活。
立即学习“前端免费学习笔记（深入）”；
- 字体：必须出现在
@font-face的src中，且 URL 完全一致（含查询参数） - CSS：preload 的
href必须和最终<link rel="stylesheet">的 URL 一致，否则 CSSOM 构建失败 - 图片：只对明确用于首屏的
<img src>或内联background-image有效；别对懒加载图或轮播第二张图 preload，易触发重复请求 - JS：极少需要 preload，除非是
type="module"入口后立即依赖的 chunk，且该 chunk 无法通过import()被提前发现
验证 preload 是否真起作用，不能只看 HTML 有没有那行
打开 Chrome DevTools → Network 面板，筛选和观察要具体：
- 按
Initiator列筛选preload（不是parser或script） - 右键表头勾选
Priority，目标请求应显示为Highest；若为High或Medium，说明as或crossorigin配置有误 - 检查响应状态码：字体或跨域资源若无
crossorigin，可能出现net::ERR_FAILED或(blocked) - 留意警告：“
preload request was not used”——说明该资源在当前页面未被实际引用
最容易被忽略的是：preload 只改下载时机，不解决资源接入问题。字体没配 crossorigin、CSS 没写 onload 切换 rel、图片 URL 不一致——这些都会让 preload 成为“完美无效代码”。
