浏览器资源下载调度依赖标签语义与属性组合，仅<link rel="preload">（需指定as）和fetchpriority="high"（Chrome 101+）能真正提升优先级；<img loading="eager">不改优先级，<script async/defer>不影响下载顺序，<link rel="prefetch">仅空闲时低优加载。
浏览器对 HTML 中资源的下载调度，不是按书写顺序线性执行，而是依赖标签语义 + 属性组合触发的优先级策略。不加干预时，<script> 和 <link rel="stylesheet"> 会阻塞渲染，而 <img> 默认是低优先级异步加载——但这个“默认”很容易被误判为“可忽略”，结果导致关键图像加载延迟、LCP 拖尾。
哪些标签和属性真正影响下载优先级
只有少数几个标签的特定属性会被浏览器识别为调度信号：
-
<link rel="preload">是唯一能主动提升资源优先级的声明式机制，必须指定as（如as="script"、as="image"），否则降级为普通<link> -
<img loading="eager">不改变优先级，只控制懒加载时机；真正影响调度的是fetchpriority="high"（Chrome 101+） -
<script async>和<script defer>影响执行时机，但不提升下载优先级——它们仍按 DOM 顺序进入队列，只是不阻塞解析 -
<link rel="prefetch">进入最低优先级队列，且仅在空闲时下载，对当前页 LCP 无帮助
常见错误：把 preload 当成“提前加载一切”
滥用 <link rel="preload"> 反而会挤占带宽，尤其在弱网下让关键资源排队更久。它只该用于明确已知将被 JS 或 CSS 引用、且当前 HTML 中未直接声明的资源：
- 预加载字体文件时，
as="font"必须配合crossorigin（即使同源），否则被丢弃 - 预加载 JS 时，若后续
<script src>的 URL 与href字符串不完全一致（含查询参数差异），浏览器不会复用，造成重复下载 - 对
<img>使用preload没有意义——浏览器已内置图像启发式调度，且preload不触发解码
fetchpriority 与 resource hint 的实际效果差异
fetchpriority 是元素级实时信号，preload 是文档级预声明，二者不可混用：
立即学习“前端免费学习笔记（深入）”；
-
<img src="hero.jpg" fetchpriority="high">在 Chrome 中会让该图片进入与 CSS 同级的高优队列，但 Safari 和 Firefox 当前忽略该属性 -
<link rel="preload" as="image" href="hero.jpg">在所有支持 preload 的浏览器中生效，但必须出现在<body>开头附近，否则可能错过早期调度窗口 - 两者同时存在时，
fetchpriority优先级更高，但仅限于 Chromium 内核；其他浏览器回退到 preload 行为
真正起效的优化不在堆砌标签，而在识别关键资源路径：首屏图像、核心字体、首屏所需 JS 模块。这些资源的调度信号必须精准匹配浏览器解析阶段——早于 CSSOM 构建时声明，晚了就失去意义。
