fetchpriority仅对<img>和<iframe>标签生效，且仅Chromium 119+（Chrome 119、Edge 101、Opera新版）完全支持；Safari 17.2+部分支持<img>，Firefox完全忽略；<link>、<script>、<video>及JS动态创建的元素均不支持。
fetchpriority 不是万能开关，它只在特定标签、特定浏览器、特定时机下起效；盲目加 fetchpriority="high" 可能稀释真正关键资源的权重，反而拖慢 LCP。
哪些标签和浏览器真正支持 fetchpriority
它目前仅对 <img> 和 <iframe> 生效，且只在 Chromium 119+（Chrome 119、Edge 101、Opera 新版）中被识别。Safari 17.2+ 仅部分支持 <img>，Firefox 完全忽略——不报错，也不调度。
-
<link rel="stylesheet">、<script>、<video>上写的fetchpriority属性，浏览器直接跳过，连日志都不会记 - JS 动态创建的
img元素，再用element.fetchPriority = "high"赋值，无效：该属性只在 HTML 解析阶段读取一次 - 空
src、src=""或靠 JS 后续注入 URL 的图片，fetchpriority不触发任何优先级调整
fetchpriority="high" 什么时候真能抢到带宽
它不是“强制插队”，而是向浏览器发出一个相对提示：这张图比默认更值得抢连接。但是否生效，取决于当前网络空闲度、是否在视口内、是否有明确尺寸等。
- 必须同时满足：
src存在 +loading="eager"（避免被 lazy 逻辑覆盖）+ 未被<link rel="preload">提前声明（preload 已锁定 Highest，fetchpriority失效） - 典型有效场景：首屏大图（LCP 候选）、轮播第一帧、无
width/height但已知关键的图（此时浏览器无法早期布局，更依赖人工提示） - 验证方式：Chrome DevTools → Network 面板 → 右键表头勾选
Priority列，目标请求应显示Highest或High；若仍为Medium，说明提示未被采纳
fetchpriority="low" 不是降级，是主动让权
它的作用不是把资源压到最低，而是显式放弃带宽竞争权，让浏览器把连接、解码资源留给更紧急的任务。
宝塔Linux面板11.3.0
下载
宝塔面板11.3.0是一款针对Linux服务器设计的可视化管理工具，通过重构核心模块实现资源占用显著降低，尤其适合低配置服务器环境。它将复杂的命令行操作转化为直观的图形界面，帮助开发者快速完成网站部署、环境配置及日常运维工作，无需专业技术背景即可高效管理服务器。
立即学习“前端免费学习笔记（深入）”；
- 适合场景：页面底部社交图标、折叠区内容（如
<details>展开前的图）、非交互型装饰图 - 不要给
loading="lazy"的图片再加fetchpriority="low"——lazy 本身已触发低优先级队列，叠加无额外收益，纯属冗余 - 可与
decoding="async"组合：前者管“多快下载”，后者管“解码是否卡主线程”，形成完整优化闭环
为什么加了却没看到 Priority 变化
最常见原因不是写错了，而是信号被更高优先级逻辑覆盖或忽略：
-
loading="lazy"且图片未进入视口时，Chrome 会强制将其优先级降为Low，此时fetchpriority="high"直接被丢弃 - 资源没有有效
src（比如 JS 动态补全），浏览器在解析阶段根本没把它当真实请求处理 - 用了
<link rel="preload" as="image">，该请求已走 preload 调度路径，fetchpriority不参与 - 跨域图片缺失
crossorigin属性，CORS 预检失败导致请求被中止，优先级提示自然失效
真正难的是判断哪张图“值得”加 high：它必须是首屏、阻塞渲染、且浏览器默认可能低估其重要性的那一个。加多了，等于没加；加错了位置，反而干扰调度器判断。
