fetchpriority 是最轻量、语义最清晰的原生优先级提示，仅对 <img> 和 <iframe> 生效，且需满足 src 存在、Chromium 112+/Safari 17.2+、未被 lazy/preload 等更高优先级逻辑覆盖；<link rel="stylesheet"> 在部分浏览器有效，而 <script> 等标签及动态创建元素均无效。
fetchpriority 是当前最轻量、语义最清晰的 HTML 原生优先级提示方式，但它不是“开关”，只在特定标签、特定浏览器、特定时机下起效；加了不等于生效，多数失效源于 loading="lazy" 覆盖、src 缺失或浏览器不支持。
fetchpriority="high" 该加在哪些元素上才真正起作用
它只对 <img> 和 <iframe> 生效，且必须满足三个硬性条件：HTML 解析时 src 已存在、浏览器为 Chromium 112+ 或 Safari 17.2+、未被更高优先级逻辑覆盖。
-
<link rel="stylesheet">上加fetchpriority="high"在部分 Chromium/Safari 中有效，但 Firefox 完全忽略 -
<script>、<picture>、<source>、<video>、JS 动态创建的<img>—— 全部无效，属性被静默跳过 -
src=""、src="data:image/..."、或靠 JS 后续赋值的src，fetchpriority不触发任何调度调整 - 已用
<link rel="preload" as="image">的资源，fetchpriority不再起作用 —— preload 已锁定Highest
为什么加了 fetchpriority="high" 却没看到 Priority 变高
最常见原因不是写错，而是信号被更高层逻辑拦截或忽略。打开 Chrome DevTools → Network 面板 → 刷新 → 右键表头勾选 Priority 列，若目标请求仍显示 Medium 或 Low，大概率是以下情形之一：
-
loading="lazy"和fetchpriority="high"同时存在：Chrome 会强制降级为Low，lazy逻辑优先级更高 -
src是空值、data-src或由 JS 动态注入：解析阶段无真实 URL，资源根本不会进入调度队列 - 图片未设
width/height且不在首屏可视区：浏览器无法参与早期布局，连“是否关键”都难以判断 - 页面在后台标签页中加载：Chrome 会整体降级所有资源优先级，
fetchpriority提示被忽略
fetchpriority="low" 不是“降级”，而是主动让出带宽
它的作用不是把资源压到最低，而是显式放弃竞争权，把连接和解码资源留给更紧急任务。适合明确非首屏、不参与 LCP、用户交互前无需加载的场景：
立即学习“前端免费学习笔记（深入）”；
- 折叠区内容（如
<details>展开前的图）：<img src="gallery-2.jpg" fetchpriority="low"> - 页脚社交图标、装饰性 banner、统计类小图
- 可与
decoding="async"组合：前者管“多快下载”，后者管“解码是否卡主线程” - 不要给
loading="lazy"的图片再加fetchpriority="low"—— lazy 本身已走低优先级队列，叠加纯属冗余
验证是否生效的关键动作
不能只看 HTML 有没有那行属性，必须进 Chrome DevTools 实测：
- Network 面板 → 刷新页面 → 筛选目标资源（如按
Name或Initiator） - 右键表头 → 勾选
Priority列 -
fetchpriority="high"应显示为Highest或High（若有 preload，则更倾向Highest） -
fetchpriority="low"多数显示为Low或Lowest；若仍是Medium，说明提示未被采纳
真正容易被忽略的是：fetchpriority 仅影响“什么时候开始下载、抢多少带宽”，不改变资源是否加载、不控制执行时机、也不保证渲染顺序 —— 它只是调度器的一个输入信号，最终决策权仍在浏览器手里。
