fetchpriority仅对和标签生效，且仅在chrome 119+、edge 101+、opera新版等chromium内核浏览器中支持；对、、等标签及firefox、safari无效。
fetchpriority只对哪些标签和浏览器生效
它目前仅在 Chromium 系列（Chrome 119+、Edge 101+、Opera 新版）中支持，且**只对 <img> 和 <iframe></iframe> 生效**。给 <link>、<script></script>、<video></video> 或动态 JS 创建的元素加该属性，浏览器直接忽略。
常见误用包括：
- 在
<link rel="stylesheet">上写fetchpriority="high"—— CSS 优先级由渲染阻塞逻辑决定，不走 fetch priority 调度路径 - 用 JS 设置
img.fetchPriority = "high"—— 该属性只在 HTML 解析阶段读取，运行时赋值无效 - 对空
src或srcdoc的<img>/<iframe></iframe>设置该属性 —— 浏览器不触发调度调整
fetchpriority="high" 什么时候真有用
它不是“强制插队”，而是向浏览器发出一个相对提示信号：这张图比默认优先级更高。但是否真提前加载，取决于当前网络空闲度、是否在视口内、资源大小等综合判断。
真正见效的场景很窄，必须同时满足：
- 资源是首屏关键内容（如 LCP 候选图、轮播第一帧）
- 已明确设置
loading="eager"（避免被 lazy 逻辑覆盖） - 没有被
<link rel="preload">提前声明（preload 本身已锁定最高优先级，再设 fetchpriority 无意义） - 图片有明确
width/height，能参与早期布局计算
示例有效写法：<img src="hero.jpg" fetchpriority="high" loading="eager" style="max-width:90%" style="max-width:90%" alt="首页主图">
fetchpriority="low" 不是“降级”，而是主动让权
它的作用不是把资源压到最低，而是显式放弃带宽竞争权，让浏览器把连接、解码资源留给更紧急的任务。适合明确非首屏、不参与 LCP、用户交互前无需呈现的资源。
典型适用：
- 页面底部社交图标、无关 banner 图
- 折叠区域内的图片（配合
details或 JS 展开逻辑） - 已启用
loading="lazy"的图片 —— 此时加fetchpriority="low"是冗余操作，因为 lazy 本身已触发低优先级策略
注意：fetchpriority="low" 和 loading="lazy" 逻辑不同：前者管“多快下载”，后者管“要不要下载”。混用需谨慎，避免信号冲突。
为什么设置了 fetchpriority 却没看到 Priority 变化
打开 Chrome DevTools → Network 面板 → 右键表头勾选 Priority 列，这是唯一可验证方式。若仍显示 Medium，常见原因有：
- 资源已缓存（缓存资源不参与 fetch queue 调度）
- 页面处于后台标签页（Chrome 会统一降级所有请求优先级）
- 同时用了
loading="lazy"或decoding="async"—— 这些属性的加载控制逻辑优先级高于 fetchpriority - 跨域图片未返回
Access-Control-Allow-Origin，CORS 预检失败导致提示失效
最关键一点：fetchpriority 是提示，不是指令。它无法覆盖浏览器底层调度策略，比如一个 4MB 的 WebP 图片，即使设了 high，仍可能排在 10KB 的关键 JS 后面 —— 因为浏览器判断 JS 对渲染阻塞的影响更大。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
