Fetch priority 怎样提示浏览器资源优先级

页面打开时，浏览器会根据资源类型、发现时机和当前加载状态安排请求。fetchpriority 的作用，是在浏览器已有判断的基础上补充“这个资源相对更重要”或“可以晚一点”的提示。它不是强制排序开关，也不会保证某张图片一定先于所有脚本下载。

实战里可以这样分工：真正影响首屏的主图才考虑 high，首屏以下且不急的图片可以用 low，没有明确判断时保留 auto。脚本还要结合 defer 或 async，不要只改一个优先级值就期待执行时机一起改变。

fetchpriority 先改的是提示，不是浏览器的硬排序

这个属性可用于 、 和 。high 表示相对更重要，low 表示相对不急，auto 表示不额外表达偏好，也是默认值。浏览器仍会结合缓存、资源类型、连接状态和自身调度模型做最终决定。

因此，看到请求顺序没有完全按标签顺序变化，不代表属性失效。更准确的理解是：它给资源调度器增加了一个作者侧信号。信号越稀缺，越容易表达真实意图；如果图片、字体、脚本都设成 high，优先级就失去了区分度。

图片和脚本怎么写才不会互相抢资源

先找出真正影响首屏的资源，再决定是否提高提示。下面的示例把四类常见资源放在一起，注释说明每个属性解决的具体问题：

这不是一套必须照抄的固定组合。比如主图已经在初始 HTML 中很早出现，可能只需要尺寸属性和合理的 fetchpriority；只有当资源发现得晚、又确实影响首屏时，才进一步考虑 preload。重复预加载、设置错误的 as，或者把同一资源声明成多个不同 URL，都会造成额外竞争。

preload、loading、defer 与 fetchpriority 的职责边界

排查资源加载时，先问“我要改变什么”，再选属性。preload 主要改变资源被发现和开始请求的时机；fetchpriority 表达相对重要性；loading="lazy" 允许不在视口附近的图片延后加载；defer 影响经典外部脚本的执行时机，不等于把脚本优先级自动降到最低。

上线前可以用资源类型、首屏影响、发现时机、是否重复声明四项做检查。若结果变差，先撤掉不必要的 high 和 preload，再重新比较，而不是继续叠加属性。

常见问题

fetchpriority="high" 会强制图片第一个下载吗？

不会。它只是提高相对重要性的提示，缓存、连接和浏览器内部策略仍可能改变实际顺序。

首屏图片已经 preload，还需要 fetchpriority 吗？

不一定。preload 解决发现时机，fetchpriority 解决相对重要性；只有两者确实对应同一个关键资源和同一性能目标时才组合。

所有统计脚本都应该设置 low 吗？

不能一概而论。先确认脚本是否参与首屏交互、是否有执行依赖，再选择 low、defer 或其他加载策略。