fetchpriority="high"不能强制抢到带宽，仅是Chromium浏览器的提示信号；必须同时满足src存在、loading="eager"、未被preload声明、首屏且参与LCP等条件才可能生效。
fetchpriority="high"到底能不能抢到带宽
不能保证，它只是个提示信号，不是强制插队指令。Chrome 119+ 会把它当参考，但最终优先级由网络空闲度、是否在视口内、是否有明确尺寸、是否已缓存等共同决定。
真正能起效的条件很窄，必须同时满足：
-
src存在且非空（src=""或 JS 后续赋值无效） -
loading="eager"（否则loading="lazy"会直接覆盖为Low） - 没被
<link rel="preload">提前声明（preload已锁定Highest，fetchpriority失效） - 图片在首屏、参与 LCP、且无
width/height导致无法早期布局时，提示才最可能被采纳
典型有效写法：<img src="hero.jpg" fetchpriority="high" loading="eager" width="1200" height="600" alt="首页主图">
哪些标签加了 fetchpriority 也白加
浏览器对 fetchpriority 的支持非常有限，很多常见写法根本不起作用，还可能误导自己。
立即学习“前端免费学习笔记（深入）”；
以下场景中，属性会被静默忽略，不报错、不调度、也不影响 Priority 列显示：
-
<link rel="stylesheet">上加fetchpriority—— CSS 加载优先级由渲染阻塞逻辑决定，不走 fetch priority 调度路径 -
<script src="app.js">或<video>上设置该属性 —— Chromium 和 Safari 都跳过解析 - JS 动态创建的
<img>，再用element.fetchPriority = "high"赋值 —— 该属性只在 HTML 解析阶段读取一次，运行时无效 -
<iframe>的srcdoc为空，或<img>的src为空字符串 —— 浏览器根本不触发调度调整
为什么 Network 面板里 Priority 没变
这不是写错了，而是信号被更高优先级逻辑覆盖或未触发调度。唯一可靠验证方式是：Chrome DevTools → Network 面板 → 右键表头勾选 Priority 列，看目标请求值。
常见原因包括：
- 资源已缓存命中 —— 不走网络调度，
Priority显示Medium是正常现象 -
loading="lazy"且图片未进入视口 —— Chrome 强制降为Low，fetchpriority="high"被无视 - 页面刚加载完就刷新 DevTools，又没勾选
Preserve log—— 初始调度决策可能未被捕获 - 请求在后台标签页中发起 —— 浏览器统一压低优先级，
high提示无效
fetchpriority="low"不是降级，是主动让权
它的作用不是把资源压到最低，而是显式放弃带宽竞争权，让浏览器把连接和解码资源留给更紧急的任务。
适合明确非首屏、不参与 LCP、用户交互前无需呈现的资源：
- 页面底部社交图标、无关 banner 图
- 折叠区内容（如
<details>展开前的图） - 已启用
loading="lazy"的图片 —— 此时加fetchpriority="low"是冗余操作，因为lazy本身已触发低优先级策略
可与 decoding="async" 组合使用：fetchpriority 管“多快下载”，decoding 管“解码是否卡主线程”，形成完整优化闭环。
真正容易被忽略的是：fetchpriority 的生效前提极苛刻，而开发者常误以为加了就起效；实际中，<link rel="preload"> 和 loading="eager" 的组合往往比盲目堆砌 fetchpriority 更可控、更可靠。
