Chrome中preload的Priority不是high，是因为as属性漏写或错误（如as="fonts"）、字体未加crossorigin导致降级为Medium/Low；Safari几乎忽略prefetch且fetchpriority仅限img标签；Firefox不支持fetchpriority但完整支持preload。
Chrome 里 preload 的 Priority 为什么不是 high
写了 <link rel="preload"> 却在 Network 面板里看到 Priority 是 Medium 或 Low，基本可以断定是 as 属性漏写或写错。Chrome 只有在明确知道资源类型时，才会赋予对应优先级：字体必须 as="font"、CSS 必须 as="style"、JS 必须 as="script"、图片必须 as="image"。写成 as="fonts"、as="css" 或直接省略，浏览器就当普通 fetch 处理，降级为默认优先级。
另一个高频原因是字体资源没加 crossorigin。哪怕同源，Chrome/Safari 也会加载完丢弃，不报错，只表现为 FOIT（Flash of Invisible Text），且 Network 里请求 Priority 显示为 Low —— 因为它被当成跨域请求但没声明策略，最终走 fallback 路径。
Safari 对 prefetch 的支持有多弱
Safari 对 <link rel="prefetch"> 的支持极其有限：只对 .js 文件有基础响应，对 .css、.jpg、.woff2 等资源基本忽略。即使写了，Network 面板也看不到请求发起，DevTools 不报错、不警告，就是静默跳过。
更关键的是，Safari 17.2+ 虽开始支持 fetchpriority，但仅限 <img> 标签，且行为不稳定；<iframe> 和所有其他标签完全无效。这意味着你在 Safari 里给首屏图加 fetchpriority="high"，大概率不会改变它的下载顺序。
立即学习“前端免费学习笔记（深入）”；
-
prefetch在 Safari 中几乎等价于不存在，别依赖它做路由预加载 - 想让 Safari 提前加载下一页资源，得用 JS 动态
fetch()+cache.put()手动缓存，或改用rel="prerender"（但仅限特定场景且已逐步弃用）
Firefox 完全忽略 fetchpriority，但 preload 还能用
Firefox 当前版本（截至 2026 年 6 月）对 fetchpriority 属性完全不识别——不报错、不执行、不调整 Priority。你在 <img> 上写的 fetchpriority="high" 或 fetchpriority="low"，跟没写一样。
但 Firefox 对 <link rel="preload"> 支持完整：只要 as 正确、位置合规（<head> 内、<meta charset> 之后）、路径合法，就能触发高优先级请求。唯一例外是字体：Firefox 同样要求 crossorigin，否则同样丢弃。
注意：prefetch 在 Firefox 默认关闭（network.prefetch-next = false），需用户手动开启才可能生效，生产环境不可依赖。
同一个 preload 在 Chrome 和 Safari 里发两次请求
如果你同时写了 <link rel="preload" as="script" href="main.js"> 和 <script src="main.js"></script>，Chrome 会复用 preload 缓存，但 Safari 可能发起两次独立请求：一次来自 preload，一次来自 script 标签。这是因为 Safari 的 preload 缓存分区与常规 fetch 不完全打通，尤其在 HTTP/2 环境下更易复现。
更隐蔽的问题是：同一资源既 preload 又 prefetch，Chrome 会发两次请求且无法复用缓存——它们走不同通道，优先级和缓存策略隔离。Safari 虽不执行 prefetch，但 preload + script 组合仍可能触发重复下载。
验证方式很简单：打开 DevTools → Network → 搜索文件名，看是否出现两条相同 URL 的请求记录，且 Initiator 列分别显示 html 和 script。
跨浏览器预加载真正难的不是“怎么写”，而是“怎么验证它真的按你预期在跑”。每个内核对 as、crossorigin、位置、时机的容忍度都不同，稍有偏差，就从“抢时间”变成“浪费带宽”。
