fetchpriority="high"不是提速开关，而是防止首屏关键图被误判为低优先级的“防降级”提示；仅chromium 112+支持，safari/firefox完全忽略，必须用于服务端直出html中带真实src的原生标签，且需搭配loading="eager"，否则被静默忽略。
fetchpriority 不是提速开关，而是防止首屏关键图被浏览器误判为低优先级的“防降级”提示。它只在 Chromium 112+（Chrome/Edge 112+、Opera 98+）中生效，Safari 和 Firefox 完全忽略，且必须配合真实 src 才能起作用。
fetchpriority="high" 必须写在原生 <img> 标签上
浏览器预扫描器只识别初始 HTML 中带 src 的 <img> 标签。以下写法全部无效：
-
<picture></picture>或<source></source>上加fetchpriority—— 属性被跳过，不解析 -
<img>或<img id="hero">后由 JS 补src—— 解析阶段无src，根本进不了高优队列 -
<template></template>里或 CMS 渲染后动态插入的<img>—— 预扫描器看不到，提示失效
唯一有效写法：<img src="hero.jpg" fetchpriority="high" loading="eager">，且该标签必须出现在服务端直出的 HTML 中。
为什么 Network 面板里 Priority 没变
这不是配置错误，而是信号被更高优先级逻辑覆盖或未触发调度。验证前先确认：
- 是否在后台标签页加载？Chromium 会主动压低所有资源优先级
- 图片是否已缓存？缓存命中时 Priority 恒为 Medium，属正常行为
- 是否同时用了
<link rel="preload" as="image">？preload 已锁定 Highest，fetchpriority被静默忽略 - 是否写了
loading="lazy"？Chrome 会强制降级为 Low，lazy 逻辑优先级高于 high 提示
真正可靠的验证方式：Chrome DevTools → Network → 右键表头勾选 Priority 列，观察目标请求值；刷新页面时务必勾选 Preserve log，否则初始调度决策可能丢失。
fetchpriority="high" 和 preload 怎么选
fetchpriority="high" 是轻量提示，<link rel="preload"> 是确定性抢时间手段。二者不叠加，且有明确分工：
- 用
fetchpriority="high"：当图已在 HTML 中、无需额外标记、且希望语义清晰时（如首屏 Hero 图） - 用
<link rel="preload" as="image" href="hero.jpg">：当图必须在 HTML 解析早期就发起请求（比如 CSS background-image 替代方案），或需跨域加载字体（此时必须加crossorigin） - 不要混用：同一张图既
preload又设fetchpriority="high"，后者冗余且无效
注意：preload 的 href 必须与最终 <img src> 完全一致（含查询参数），否则缓存不命中，等于白配。
真正容易被忽略的是：fetchpriority 生效的前提非常硬——它只在初始 HTML、真实 src、前台标签页、未被其他机制覆盖这四个条件同时满足时，才可能让 Priority 显示为 High。多数失效不是代码写错，而是没意识到这些隐性约束。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
