fetchpriority 属性仅对 和 标签生效，chrome 119+ 及基于 chromium 的新版浏览器支持，用于向加载调度器提供 high/low/auto 优先级提示，影响资源获取顺序而非强制插队。
fetchpriority 属性该加在哪些标签上
fetchpriority 目前只被 Chrome 119+（及基于 Chromium 的新版 Edge、Opera 等）支持，且**仅对 <img> 和 <iframe></iframe> 标签生效**。给 <script></script>、<link> 或 <video></video> 加这个属性完全无效，浏览器会忽略。
常见误用场景：
- 在
<link rel="stylesheet">上写fetchpriority="high"—— 无作用，CSS 加载优先级由渲染阻塞特性决定，不走 fetch priority 机制 - 给动态插入的
<img>元素 JS 设置element.fetchPriority = "high"—— 不生效，该属性是 HTML 解析时读取的枚举值，JS 设置不触发重新调度
high / low / auto 三个值的实际效果差异
fetchpriority 不是“强制插队”，而是向浏览器的资源加载调度器提供一个**提示信号**。最终是否提前加载，取决于当前网络状态、并发连接数、资源大小、是否在视口内等综合判断。
典型表现：
-
fetchpriority="high"：让浏览器更倾向把这张图放进高优先级队列，尤其在页面刚加载、空闲连接多时见效明显；但若它是个 5MB 的 WebP，仍可能被小体积关键 JS 挡在后面 -
fetchpriority="low"：明确告诉浏览器“这图不急”，比如懒加载占位图、折叠区域内的图、或loading="lazy"已启用的图——此时设为low可进一步降低竞争带宽的概率 -
fetchpriority="auto"（默认）：浏览器按自身启发式规则判断，通常对首屏大图、loading="eager"图给予较高权重
示例：
@@##@@<br>@@##@@
和 loading、decoding、fetching 的配合关系
fetchpriority 必须和其他加载控制属性协同使用，否则容易互相抵消效果：
- 和
loading="lazy"同时出现时，fetchpriority="high"会被忽略——因为 lazy 本身意味着“非即时可见”，浏览器认为逻辑冲突，直接降级为auto -
decoding="async"影响的是解码阶段，不影响下载顺序；但搭配fetchpriority="high"能让“下载快 + 解码不卡主线程”形成完整优化闭环 - 对跨域资源（如 CDN 图片），需确保服务端返回
Access-Control-Allow-Origin，否则fetchpriority提示可能因 CORS 预检失败而失效
怎么验证它真的起作用了
不能只看 Network 面板里时间戳，要查浏览器内部调度行为：
- 打开 Chrome DevTools → Network → 右键表头 → 勾选
Priority列 → 观察对应图片请求的优先级是否从Low变为High（注意：这里显示的是实际调度优先级，不是你写的字符串） - 在 Performance 面板录制加载过程 → 过滤
ImageDecode和ResourceReceive事件 → 看 high 优先级图是否比同批其他图更早进入 receive 阶段 - 注意陷阱：如果页面用了 Service Worker，资源可能被拦截并重发，此时 DevTools 显示的 Priority 是 SW 发起请求时的值，未必反映原始
fetchpriority提示
真实项目中，首屏关键图加 fetchpriority="high" 通常能抢到前 200ms 的连接窗口；但若服务器响应慢或 TTFB 高，这个优势会迅速被吞掉——它优化的是客户端调度，不是网络链路本身。
