fetchpriority只对<img>和<iframe>标签生效，且必须带真实非空的src（或srcdoc）；<script>、<link rel="preload">、<picture>、<source>及JS动态创建元素均无效，浏览器静默忽略；Chrome 119+/Edge 101+/Opera新版完全支持，Safari 17.2+仅部分支持<img>，Firefox完全不识别。
fetchpriority只对哪些标签和属性生效
它只在 <img> 和 <iframe> 上起作用，且必须带真实非空的 src（或 srcdoc）——src=""、data-src、JS 后续赋值都无效。其他全忽略：<script>、<link rel="preload">、<picture>、<source>、JS 动态创建的元素，写了 fetchpriority 浏览器静默丢弃，不报错也不调度。
Chrome 119+ / Edge 101+ / Opera 新版完全支持；Safari 17.2+ 仅部分支持 <img>；Firefox 完全不识别——不是兼容性警告，是彻底跳过解析。
为什么加了 fetchpriority="high" 却没看到 Priority 变高
不是写法错，而是信号被更高优先级逻辑覆盖。打开 Chrome DevTools → Network 面板 → 右键表头勾选 Priority 列，若仍显示 Medium 或 Low，大概率是以下原因：
-
loading="lazy"和fetchpriority="high"同时存在：Chrome 强制降级为Low，lazy 逻辑优先级更高 -
src是空字符串、data-src、或靠 JS 注入：HTML 解析阶段没读到真实资源地址，调度器根本不会把它放进队列 - 图片没设
width/height，又不在首屏可视区：浏览器无法参与早期布局计算，“是否关键”都判断不了 - 已被
<link rel="preload" as="image">提前声明：preload 已锁定Highest，fetchpriority冗余失效 - 页面处于后台标签页：所有资源优先级被系统性压低，
high提示无效
fetchpriority="high" 和 preload 怎么选、怎么共存
fetchpriority 是提示信号，preload 才真正抢时间。二者不是叠加关系，而是互斥路径：
立即学习“前端免费学习笔记（深入）”；
-
<link rel="preload" as="image" href="hero.jpg">必须配对as和crossorigin（字体必须加，图片通常不用，除非跨域且响应头缺Access-Control-Allow-Origin: *） -
href值必须与最终<img src>完全一致（含查询参数），否则缓存不命中 -
preload加载完只是进缓存，CSS 需onload="this.rel='stylesheet'"才触发解析，JS 需手动插入 DOM 才执行 - 同一资源既
preload又设fetchpriority="high"：后者被忽略，无额外收益
最容易被忽略的底层限制
这个属性只在 HTML 解析阶段读取一次，DOM 构建完成后，再通过 JS 修改 element.fetchPriority 或动态补全 src，调度器早已完成决策，信号彻底丢失。
它不改变资源是否加载，只影响“什么时候开始下载、抢多少带宽”。加得太多反而稀释真正关键资源的权重——比如给所有 <img> 都设 high，浏览器会把它们和普通图一起归入 High 队列，LCP 候选图的实际调度优势就没了。
