fetchpriority="high"能让chromium 112+优先调度首屏关键图下载，但只是防降级提示而非加速开关；必须搭配src（真实非空）、loading="eager"、html width/height属性才可能生效，且仅chrome/edge支持，safari部分支持，firefox完全忽略。
直接说结论：fetchpriority="high" 能让 Chromium 浏览器（Chrome/Edge 112+）在资源调度时优先下载这张图，但**它不是加速开关，而是防止被降级的提示**——首屏大图默认也是 Medium 优先级，不加这个属性，浏览器可能根本没把它当 LCP 关键资源看。
fetchpriority="high" 必须搭配哪些 HTML 属性才生效
单独写 fetchpriority="high" 几乎一定无效。它依赖浏览器在 HTML 解析第一毫秒就识别出“这是关键图”，所以必须同步满足：
-
src必须是真实、非空、可访问的 URL（不能是src=""、data-src或 JS 后续赋值） - 必须配
loading="eager"—— 如果写了loading="lazy"，Chrome 会直接忽略fetchpriority并强制降为Low -
width和height必须作为 HTML 属性存在（不是仅靠 CSS），否则布局无法早期计算，LCP 判定延迟，提示信号也难被采纳 - 不能包裹在
<picture></picture>外层或自定义组件里；如果用了<picture></picture>，fetchpriority只能写在内部的<img>fallback 上，<source></source>上加了也白加
为什么 Network 面板里 Priority 还是 Medium
这不是代码写错了，而是几个常见拦截条件同时触发：
- 图片已被缓存 —— 缓存命中时 Priority 恒为
Medium，和属性无关 - 页面在后台标签页中加载 —— Chromium 主动压低所有资源优先级，
fetchpriority提示被静默忽略 - 同时用了
<link rel="preload" as="image">加载同一张图 ——preload已锁定Highest，fetchpriority成为冗余 - 目标请求没勾选 DevTools 的
Preserve log，刷新后初始调度决策丢失，看不到真实 Priority 变化
fetchpriority="high" 和 preload 怎么选
两者机制不同，适用场景有明显区分：
-
<link rel="preload" as="image" href="hero.jpg" fetchpriority="high">：适合服务端能提前确定 URL 的场景（如静态首页），它绕过 DOM 解析顺序，**真正抢时间**；必须带as="image"，href 要和最终<img src>完全一致（含查询参数） -
<img src="hero.jpg" fetchpriority="high" loading="eager">：适合 CMS 动态渲染、URL 由后端拼接的场景，它不改变发起时机，只影响调度队列权重 - 别混用 —— 同一张图既
preload又设fetchpriority="high"，后者基本失效；更糟的是srcsetfallback 格式不一致（比如preload是 webp，<img>fallback 是 jpg），可能触发重复下载
容易被忽略的兼容性和边界问题
最常踩的坑不是怎么写，而是没意识到它有多“脆弱”：
- Safari 17.2+ 仅部分支持
<img>，Firefox 完全忽略 —— 如果你靠它做核心性能优化，必须同步准备<link rel="preload">fallback -
fetchpriority对 CSSbackground-image、JS 动态创建的<img>、<video></video>、<script></script>全无效，写了也白写 - 不要给所有首屏图都加
high—— 浏览器会把它们一起放进 High 队列，反而稀释真正 LCP 候选图的权重；建议严格控制在 1–2 张（比如 Hero 图 + 核心产品主图） - 验证唯一可靠方式：Chrome DevTools → Network → 右键表头勾选
Priority列 → 找到对应请求，看是否显示Highest或High（禁用缓存、前台标签页、首次加载）
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
