只给 LCP 图加一个 fetchpriority=high，Google 实测 2.6s 掉到 1.9s——但 90% 的站点把它加错了元素

阿跨·跨端开发内容创作者 2026-09-18 10 阅读

2026 年，还有大约 38% 的移动站点过不了 2.5 秒的 LCP 门槛。很多人第一反应是「压缩图片」，结果压完了一看报表，纹丝不动。问题往往不在图片有多大，而在浏览器根本没在正确的时间、用正确的优先级去拿这张图。

先说结论：LCP 的耗时被拆成四段——TTFB、资源加载延迟、资源加载时间、渲染延迟。绝大多数站点的瓶颈都在「资源加载延迟」这一段，也就是图片被发现得太晚。而解决它只需要两个字符串：fetchpriority="high" 和 rel="preload"。但前提是——你得知道哪个元素才是真正的 LCP 元素，以及你为什么一直在给错误的元素挂高位。

为什么「eager」不等于「优先」

大多数人对比的是 loading="lazy" 和 loading="eager"。这是错的维度。

loading="eager" 只是告诉浏览器「别等布局计算，看到就下载」。它确实去掉了懒加载的惩罚，但并没有把这张图插队到 CSS、字体、脚本前面——它只是排进了普通队列。而浏览器默认给图片的优先级是 Low 或 Medium，也就是说，你的 hero 图很可能排在几 KB 的 analytics 脚本后面。

fetchpriority="high" 完全不一样。它是直接对网络栈喊话：其他非关键下载先让让，带宽优先给这张图。一个是「别拦我」，一个是「让我插队」。这两件事不能互相替代。

还有一个反直觉的点：浏览器在解析完 HTML、算完布局之前，根本不知道哪张图会是 LCP 元素。等它算出来，请求早就发出去了、队列早就排好了。fetchpriority 的价值，就是在浏览器还没「想明白」之前，人工把正确答案告诉它。

真实数据：一个属性值多少钱

在 4G 限速（20 Mbps 下行、20 ms RTT）下，加载一张 180 KB 的 AVIF hero 图加 12 个附属资源，WebPageTest 的对照结果是这样：

不加任何提示（图片在首屏内）：LCP 1840 ms，hero 图 TTFB 320 ms
只加 fetchpriority="high"：LCP 1540 ms，TTFB 210 ms
preload + fetchpriority="high"：LCP 1280 ms，TTFB 95 ms
CSS 背景图、不加提示：LCP 2610 ms，TTFB 890 ms
CSS 背景图 + preload + fetchpriority="high"：LCP 1310 ms，TTFB 110 ms

两个信息量极大的结论藏在这张表里。

第一，preload + fetchpriority 的组合永远比单独用属性更强。因为 preload 把「发现资源」这一步提前到了 DOM 解析之前，干掉了扫描器发现延迟；fetchpriority 再保证它不被别的 preload 挤下去。一个解决「找没找到」，一个解决「排没排队」。

第二，那个 890 ms 的 TTFB 不是网速慢，是「请求还不存在」。CSS 背景图对预加载扫描器是隐形的——浏览器必须先下载并解析那个提到它的 CSS 文件，才知道要请求它。这 700 毫秒是纯粹的等待。

Google 自己的 2026 测试里也有类似数字：只给首屏 hero 图加 fetchpriority="high"，LCP 从 2.6 秒降到 1.9 秒，一个 HTML 属性换来 700 ms。

90% 的人踩的四个坑

坑一：给 CSS 背景图加 fetchpriority。 这个属性只对真正的 <img> 标签和 rel="preload" 的 <link> 生效。如果你的 hero 是背景图，属性会被静默忽略，什么都不发生。正确做法是在 <head> 里补一行 preload，或者干脆把 hero 改成 <img>。

坑二：给五张图都标 high。 如果所有东西都是高优先级，那就等于没有优先级。同源并发连接数是有上限的（HTTP/1.1 通常 6 条，HTTP/2 虽多路复用但带宽仍然有限）。标了五张 high，它们会互相抢占，等于白标。一页只该有一张 high——就是那个 LCP 元素。

坑三：fetchpriority="high" 和 loading="lazy" 写在同一张图上。 这俩语义直接打架：一个喊「立刻拿」，一个喊「靠近视口再说」。浏览器会默认按 eager 处理，但这个组合本身就是错的，等于浪费了这个提示。

坑四：图片忘了写宽高。 这不算 fetchpriority 的锅，但两者在实践里绑死。没有显式 width/height，浏览器无法提前预留空间，图片加载完会顶一下布局，把刚赚回来的 LCP 又用 CLS 亏回去。

怎么找对那个元素

别猜，去测。Chrome DevTools 的 Network 面板右键列头打开 Priority 列，重载页面，看你的 LCP 图是不是 Highest/High，屏外图是不是 Low。Lighthouse 11+ 有一个专门的「Optimize the LCP image」审计项，会直接告诉你哪个元素少了 fetchpriority="high"。Performance Insights 面板的「LCP by phase」能把四段耗时拆开——如果「Resource load delay」占大头，那优先级提示就是对症的药。

最后给出可直接抄的一段。移动端 hero 图的正确写法：

<img
  src="/hero.avif"
  srcset="/hero-400.avif 400w, /hero-800.avif 800w, /hero-1600.avif 1600w"
  sizes="(max-width: 800px) 100vw, 800px"
  fetchpriority="high"
  loading="eager"
  decoding="sync"
  width="1600" height="900"
  alt="产品主图">

fetchpriority="high" 只在支持它的浏览器生效（Chrome 101+、Edge 101+、Firefox 132+、Safari 17.2+），旧浏览器直接忽略，无报错、无副作用。这是一个零风险的渐进增强。

下一步很简单：打开你排名最高的五个落地页的 PageSpeed Insights，如果看到「Largest Contentful Paint image was lazily loaded」这条诊断，那你今天能找到的最高杠杆的优化就在这里了。先修它，再去碰压缩和格式。

评论区

0 条评论

登录后可评论。