Confusion Around Next.js <Image> Component for LCP / Above-the-Fold Images

[abhishekmardiya]

Summary

I’m a bit confused about how to properly configure the Next.js <Image> component when the image is above the fold and also the LCP (Largest Contentful Paint) element.

Current Understanding (Plain HTML)

In standard HTML, for an LCP image, we would typically do something like:

<img
  src="/hero.jpg"
  alt="Hero"
  loading="eager"
  fetchpriority="high"
/>

This makes sense because:

• loading="eager" → ensures the image is not lazy-loaded
• fetchpriority="high" → signals to the browser that this resource is important (LCP candidate)

This setup is straightforward and aligns with performance best practices.

---

The Confusion in Next.js

According to the Next.js documentation for the <Image> component:

https://nextjs.org/docs/app/api-reference/components/image#preload

When not to use it:

• When the loading property is used.
• When the fetchPriority property is used.

It mentions not to use preload together with loading.

So which configuration is correct for an above-the-fold LCP image in Next.js?

Option 1

<Image
  src="/hero.jpg"
  alt="Hero"
  loading="eager"
  fetchPriority="high"
/>

Option 2

<Image
  src="/hero.jpg"
  alt="Hero"
  loading="eager"
  preload
/>

That makes me unsure about the correct way to configure an above-the-fold LCP image in Next.js.

Would really appreciate clarification on the intended pattern for LCP images so I can avoid misconfiguration and follow the framework’s performance guidance correctly.

Additional information

No response

Example

No response

[icyJoseph]

This is a lovely topic...

So preload is more about starting to download an asset, before it is actually discovered. If your LCP, over the fold image, is the buried under tons of CSS links, JS scripts, and other HTML, it won't be discovered and queued for download until the browser gets to that part of the HTML.

loading is more about, after discovery, should the browser download it eagerly, or is it ok to wait, as a function of the distance to the viewport. Note that, even if in the viewport, a lazy loaded image, gets deprioritized in favor of other assets, which is why you definitely don't want to lazy load an LCP candidate, above the fold etc. - there's a level of uncertainty that you opt-in to with lazy loaded images, which is why it is better to be explicitly eager!

fetchPriority is more like, ok, we have discovered the image, and are about to download it, but there's other assets being downloaded, let's hint to the browser that our asset should be pushed forward in the queue.

When you preload an asset, it is queued to be downloaded when the browser discovers its link in the head of the document, likely before anything else. The img tag that renders the image, might not even be in the document yet as the HTML chunks arrive.

Whereas, loading is, after discovery, as a function of distance to the viewport, download it. Since next/image defaults to lazy loading, you have to make it explicitly eager, and because the asset was just discovered, you give it high fetch priority.

As with most things in webdev, here you have to make a choice. For a single, clear LCP hero image, using preload is a good default. For many other cases, eager loading with high priority may be the better fit.

When you say in plain HTML, I'd do this, you are considering only the case where discoverability of the image asset is not a problem.

• https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/rel/preload

There’s a lot of nuance here, but the key distinction is whether you’re solving late discovery or network prioritization.

[abhishekmardiya]

Super helpful explanation — this really clarified things for me. Thank you so much!

[abhishekmardiya]

Hi, @icyJoseph

I'm facing this issue with LCP image optimization in Next.js.

When I use loading="eager" together with fetchPriority="high", I receive a warning related to image preloading.

However, when I switch to using only preload, I receive a warning related to image fetch priority.

Due to this restriction in Next.js — where preload cannot be used alongside loading and fetchPriority — I’m unable to fully satisfy Lighthouse recommendations for optimizing the LCP image.

Could you please clarify what the recommended approach is in this scenario for properly optimizing the LCP image?

[icyJoseph]

I think you should also judge lighthouse btw.

What restriction are we talking about again, and how are you unable to? I know the docs have this decision tree kind of style there, but if you want to check boxes on some automated tool, go for it. That checklist is made from best practices for a global audience of applications, streaming, non-streaming etc, and it is not rare for those to have false negatives too.

As I said above:

As with most things in webdev, here you have to make a choice.

• "fetchpriority=high should be applied" False positive

In the Chrome dev tools, go to performance and profile your tab. There's a network track, find the image there, and check if it is fetching at a high priority.

[abhishekmardiya]

Got it — thanks for the explanation.