preload用错as值会导致优先级降为low，因浏览器仅依赖as属性判断资源类型；漏写crossorigin致字体加载失败；prefetch与preload调度逻辑不同，混用会错位争抢连接；preconnect仅对跨域有效，同域滥用反拖慢DNS；fetchpriority在Safari中不生效。
preload 用错 as 值会导致优先级直接掉到 low
浏览器对 preload 的资源类型判断完全依赖 as 属性，不是靠文件后缀或 MIME 类型猜。写错或漏写，它就当普通 fetch 处理，Priority 降为 low，哪怕你加了 fetchpriority="high" 也无效。
常见错误：
-
as="font/woff2"→ 应该是as="font" -
as="style.css"→ 应该是as="style" - 字体 preload 漏写
crossorigin→ Chrome 120+ 会拒绝加载，Priority 显示为undefined或直接失败 - CSS preload 忘记加
onload切换rel→ 资源下完不解析，首屏仍白屏
prefetch 和 preload 在带宽争抢中根本不在同一队列
preload 请求 Priority 显示为 high，prefetch 是 low，但它们调度逻辑不同：preload 强制当前导航阶段加载，prefetch 等空闲时才发。混用时不会“抢”，而是“错位”——把本该 prefetch 的下一页 JS（如 detail.js）写成 preload，它就会挤掉 critical.css 或首屏图的连接槽。
验证方式：
立即学习“前端免费学习笔记（深入）”；
- 打开 Chrome DevTools → Network 面板 → 右键表头勾选
Priority - 观察同域下多个
preload请求是否都标high：如果是，说明没被降级；但如果页面卡顿，大概率是它们在争 TCP 连接 -
prefetch请求在 Network 中常显示为pending很久，这是正常行为，不代表失效
preconnect 对跨域第三方资源才有意义，同域滥用反而拖慢 DNS
preconnect 做的是 DNS + TCP + TLS 三步预连接，耗时约 300–600ms。对同域资源（比如 CDN 和主站同域），浏览器已有连接复用机制，加 preconnect 不仅无效，还可能触发多余 DNS 查询，尤其在弱网下更明显。
正确用法只限于明确跨域且高概率使用的第三方：
<link rel="preconnect" href="https://fonts.googleapis.com">-
<link rel="preconnect" href="https://cdn.example.com" crossorigin>（注意带crossorigin） - 避免对
https://api.example.com加 preconnect —— 它通常走 fetch/XHR，不走 HTML 解析流，预连无意义
fetchpriority="high" 在 Safari 里完全不生效
fetchpriority 是 Chrome 101+ 支持的属性，Firefox 部分支持，Safari 当前（2026 年）仍无任何实现。你在 <img> 上加 fetchpriority="high"，Chrome 里 Priority 变成 Highest，Safari 里还是默认 Low。
这意味着：
- 不能靠它兜底关键图加载顺序，必须配合
preload或提前出现在 HTML 中 - 如果页面依赖
fetchpriority实现首屏渲染节奏，iOS 用户实际体验会严重劣化 - DevTools 里看到的 Priority 是当前浏览器实际调度结果，不是“理论值”——切勿在 Safari 下信这个列
真正容易被忽略的点是：资源提示符不是独立生效的开关，它们嵌在 HTML 解析流里，和标签出现位置、浏览器状态、网络条件强耦合。一个 preload 标签写在 </head> 后面，或者被 JS 动态插入，就失去预加载意义；preconnect 如果写在 <body> 里，多数浏览器压根不执行。这些细节不看 Network 面板里的 Priority 和 Timing，只靠代码静态检查是发现不了的。
