preload未提速大概率因未生效：必须置于最前、as类型精准（如as="font"必配crossorigin）、路径完全匹配，否则priority降为low或请求被忽略。
优化关键渲染路径中的文档资源加载">
写了 link rel="preload" 却没提升首屏速度？大概率是它根本没生效，或者加载了但没用上——preload 不是“加了就快”，而是必须卡在解析早期、类型明确、路径精准，缺一不可。
为什么 preload 文档资源（如 HTML 模板、JSON 接口）几乎从不推荐
rel="preload" 对 as="document" 或未声明 as 的 HTML/JSON 资源基本无效，浏览器既不提升优先级，也不进专用缓存池。更关键的是：这类资源通常由 JS 主动 fetch() 触发，而 preload 无法替代 JS 控制流。
- HTML 模板（如
/templates/card.html）：浏览器不识别as="document"的预加载语义，实际 Priority 显示为Low，Initiator 是(Other) - JSON 接口（如
/api/user.json）：必须配as="fetch"+ 服务端响应头Access-Control-Allow-Origin，否则请求被静默丢弃；且仅当该 URL 确实被后续fetch()调用时才复用，否则白加载 - 没有
as属性的href：一律降级为普通fetch()，Priority 不变，CSP 和缓存策略也按默认处理
哪些文档类资源真能用 preload，且必须这么干
只有两类例外值得写 preload：内联 JS 依赖的外部模块（非 type="module"）、以及被关键 CSS 引用的字体文件。它们处在渲染链路的“隐性断点”上，自然加载会滞后。
-
as="script"：适用于同步执行的关键脚本（如埋在里的初始化逻辑），且不能带async或defer；若已有defer，preload可能引发重复下载 -
as="font"：必须配crossorigin（同源也要加），且href必须和 CSS 中@font-face src的 URL 完全一致（含查询参数、大小写）；漏掉任一条件，字体加载会失败或重拉一次 -
as="style"：只对尚未在 HTML 中声明的 CSS 有效（比如关键 CSS 已内联，而完整样式表在底部引入），需配合onload="this.rel='stylesheet'"手动挂载
preload 写错位置等于没写
preload 标签必须出现在 最前面，紧贴 <meta charset> 后或 <title></title> 前。浏览器只在 HTML parser 初期识别它，之后任何位置都无效。
- 放在
<link rel="stylesheet">下方：首屏字体或 CSS 加载延迟 200ms+，LCP 直接恶化 - 用 JS 动态插入（
document.createElement('link')）：Initiator 显示为(Other)，Priority 为Low，不触发高优调度 - 塞在
里：标签被忽略，Network 面板里根本搜不到对应请求
怎么确认 preload 真起作用了
别信控制台没报错，打开 Chrome DevTools → Network 面板 → 刷新页面 → 筛选 Initiator: preload：
- 看到状态码
200且Priority是Highest或High→ 成功 -
Initiator是other或请求状态为blocked→ 路径错、被 HTTP/2 Server Push 拦截、或跨域没配crossorigin - 完全搜不到
preload请求 → 标签不在前部，或被注释/条件编译移除了
最常被忽略的是：preload 只管下载，不管使用。CSS 要手动改 rel，字体要确保 @font-face 匹配，JS 要等时机执行——下载完就结束，后面一步都不能少。
