fetchpriority="high"仅对、及部分浏览器下的生效，chrome 112+和safari 17.2+支持，firefox完全忽略；其他标签如、、及js动态创建元素均无效。
fetchpriority="high"到底该加在哪些标签上
它只对 <img src="">、<iframe src=""></iframe> 和部分浏览器下的 <link rel="stylesheet"> 生效，其他标签写了也白写。Chrome 112+ 和 Safari 17.2+ 才认这个属性，Firefox 完全忽略——不是报错，是直接跳过。
常见误用场景：
-
<script src="app.js"></script>加fetchpriority="high"：无效，浏览器当没看见 -
<picture></picture>或<source></source>标签里套fetchpriority：不解析，也不触发任何调度变化 -
<link rel="preload">同时设fetchpriority="high"：冗余，preload 本身已锁定 Highest 优先级 - JS 动态创建的
<img>，再用element.fetchPriority = "high"赋值：属性只在 HTML 解析阶段读取一次，运行时改无效
为什么加了 fetchpriority="high" 却没看到 Priority 变高
不是代码写错了，而是信号被更高层逻辑覆盖或拦截了。打开 Chrome DevTools → Network 面板 → 右键表头勾选 Priority 列，如果目标请求仍显示 Medium 或 Low，大概率是以下原因：
-
loading="lazy"和fetchpriority="high"同时存在：Chrome 会强制降级为Low，lazy 逻辑优先级更高 -
src是空字符串、data-src或靠 JS 后续注入：必须在 HTML 源码中就有真实src值，否则解析器根本不会把它放进资源队列 - 图片没设
width/height，又不在首屏可视区：浏览器无法参与早期布局计算，可能连“是否关键”都判断不了，提示自然失效 - 资源已被
<link rel="preload">提前声明：preload 已占最高位，fetchpriority 不再起作用
fetchpriority="low" 的真实用途不是“降级”，而是让权
它不是把资源扔到最后，而是主动告诉浏览器：“这张图不抢带宽，请把连接和解码资源留给更紧急的任务”。适合用在明确非首屏、非交互、且加载时机宽松的地方：
- 折叠区内容（如
<details></details>展开前的图片）：<img src="gallery-2.jpg" fetchpriority="low"> - 页脚社交图标、装饰性 banner、统计类小图
- 与
decoding="async"组合使用：前者管“多快下载”，后者管“解码是否卡主线程”，两者配合才完整 - 避免和
loading="lazy"叠加：lazy 本身已走低优先级队列，再加fetchpriority="low"纯属冗余，无额外收益
替代 background-image 的关键图该怎么提优
CSS 中的 background-image 完全不受 fetchpriority 影响——它由样式层触发，不在 HTML 解析器的资源发现路径里。想优化首屏关键背景图，只有两条路可走：
- 改用语义化
<img>替代：用position: absolute+object-fit: cover+aspect-ratio模拟铺满效果，并加上fetchpriority="high" decoding="async" - 用
<link rel="preload">主动预加载：放在里，必须带as="image"，例如<link rel="preload" href="hero-bg.jpg" as="image"> - 不要给条件性加载的背景图（如主题切换后才出现的）做 preload 或 fetchpriority：带宽浪费，且可能触发重复请求
- 验证方式不变：Network 面板看
Priority列是否变成High或Highest；若仍是Medium，说明资源未被 HTML 解析器提前识别
src 的 <img> 或 <link rel="stylesheet">，且浏览器版本达标、没被 lazy 或 preload 覆盖。其余所有“看起来应该有用”的写法，基本都在白忙活。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
