fetchpriority 是 chromium 识别的提示信号，对 lcp 图像生效需 html 结构让预扫描器在首毫秒发现该图；常见失效原因包括动态渲染、空 src、picture fallback 失败、web component 封装等；必须搭配真实 src、loading="eager"、html width/height 属性，且不与 preload 冲突；仅 chrome 支持，验证需看 network priority 列是否为 highest/high。
fetchpriority 不是“指令”，而是 Chromium 浏览器（Chrome/Edge 112+）能识别的提示信号；它对 LCP 图像是否起效，取决于 HTML 结构是否让浏览器在解析首毫秒就“看见”这张图。
为什么 fetchpriority="high" 常常没反应
常见错误不是属性写错，而是结构挡住了预扫描器（preload scanner）——它只扫纯 HTML 文本流，不执行 JS、不解析 CSS、不进 <template></template> 或自定义元素内部。
-
img标签被v-if、ngIf、ng-show或 React{condition && <img>}动态渲染 → 首屏 HTML 里根本没这个标签，fetchpriority无处依附 -
src是空字符串、about:blank或data-src→ 预扫描器忽略，不触发请求，fetchpriority失效 - 用
<picture></picture>但所有<source></source>的media都不匹配，且<img>自身没src→ fallback 失败，资源未声明 -
img被包裹在<slot></slot>、<my-banner></my-banner>等 Web Component 内部 → 预扫描器停在自定义标签边界，不深入
fetchpriority="high" 必须搭配的 HTML 属性
单独加 fetchpriority 很难见效，它依赖浏览器早期识别出“这是关键图”。必须同时满足：
-
src是真实、可访问的 URL（非空、非占位符），且与最终加载路径完全一致（大小写、斜杠、查询参数都不能差） -
loading="eager"—— 否则 Chrome 直接忽略fetchpriority（loading="lazy"与 high 冲突） -
width和height写在 HTML 属性里（不是仅靠 CSS），否则布局引擎无法早期计算，LCP 判定延迟 - 不能是
background-image——fetchpriority对 CSS 触发的资源无效，必须改用<img>标签
和 <link rel="preload"> 混用的风险
两者目标一致，但机制不同：preload 是主动提前发起请求，fetchpriority 是对已声明资源的调度提示。混用同一张图容易出问题：
- 如果
<link rel="preload" href="hero.jpg" as="image">和<img src="hero.jpg" fetchpriority="high">同时存在，浏览器通常以preload为准，fetchpriority成为冗余 - 更糟的是：若
preload用webp，而img的srcsetfallback 是jpg，可能触发重复下载 - 正确做法：确定 URL 的首屏图，优先用
<link rel="preload">（兼容性更好）；CMS 动态吐出的图，才用fetchpriority="high"
验证是否真生效的唯一方式
别信代码写了就起作用。打开 Chrome DevTools → Network → 右键表头勾选 Priority 列，然后硬刷新（禁用缓存）：
- 目标请求的
Priority显示Highest或High→ 提示被识别 - 仍显示
Medium或Low→ 检查是否被懒加载脚本覆盖、是否在后台标签页、是否用了<picture></picture>却没兜底src - 注意：
fetchpriority在 Safari/Firefox 完全无效，只看 Chrome 行为
真正卡住 LCP 的，从来不只是“谁先下载”，而是“谁先准备好可绘制”——fetchpriority 只管前半程，尺寸、格式、解码、布局都得跟上，漏一环就白配。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
