Mantys Core

The LCP image is not the same on mobile and desktop: how to preload the right one

The one-sentence summary: when the largest image differs between phone and desktop, a single preload makes one of them download an image it will not show, or download the hero twice, and the fix is one preload per device, with the same srcset and sizes as the image, placed right after the viewport tag.

By · · 7 min

You added a preload for the hero image, as every guide recommends. On desktop the Largest Contentful Paint improved. On mobile it did not, and PageSpeed now warns that a preloaded image was not used, or the network panel shows the hero downloaded twice.

The preload is not wrong in itself. It is aimed at one device, and the other device pays for it.

Why the LCP image changes with the screen

  • Different layouts: on desktop the hero image is the largest element; on a phone, the title or an image lower in the column takes its place.
  • Duplicated sections: page builders often show one section on desktop and another on mobile, each with its own image, the other one hidden.
  • Art direction: a cropped, portrait version of the hero for phones.
  • Same image, different size: one file in several widths, where the phone should download a small one.
  • A background image: when the hero is a CSS background, the browser discovers it even later, a case covered in our guide on background image heroes.

Find the LCP element on each device

Run PageSpeed on mobile and on desktop, and open the “Largest Contentful Paint element” diagnostic in each tab. Or record in the DevTools Performance panel with mobile emulation: the LCP marker names the element. Do it for both sizes; do not assume.

Console: which element is the LCP here?
new PerformanceObserver(l => {
  const e = l.getEntries().at(-1);
  console.log('LCP', Math.round(e.startTime), e.element, e.url);
}).observe({ type: 'largest-contentful-paint', buffered: true });

The four mistakes that waste the preload

1. One preload for everybody. The desktop hero is preloaded for all visitors. Phones download a large image they will never show, at high priority, competing with their real LCP. Signature: the “preloaded but not used” warning on mobile.

2. A preload without the image’s srcset. The preload points to one file, while the <img> picks another width from its srcset. The browser downloads both. Signature: the same image twice in the network panel, in two sizes.

3. A preload placed before the viewport tag. Until the browser reads <meta name="viewport">, a phone lays the page out as if it were about 980 pixels wide. A responsive preload read before that tag is resolved for that width, so the phone fetches a candidate that is too large, then the right one. Signature: a double download on mobile only.

4. The LCP image is lazy loaded. A loading="lazy" on the hero, often added by a theme or a plugin to every image, tells the browser to wait for layout before fetching it. Signature: the image request starts late, after the stylesheets.

Key infos
  • One preload per device when the LCP image differs.

  • Same image in several widths: one preload carrying the same srcset and sizes as the image.

  • Place the preload right after the viewport tag, before the stylesheets.

  • Never lazy load the LCP image; give it high fetch priority instead.

The fix, case by case

Different image per device. One preload each, split by a media query that matches your theme’s breakpoint:

HTML, in <head>, right after the viewport tag
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel="preload" as="image" href="/uploads/hero-mobile.webp"
      media="(max-width: 768px)" fetchpriority="high">
<link rel="preload" as="image" href="/uploads/hero-desktop.webp"
      media="(min-width: 769px)" fetchpriority="high">

Same image, several widths. One preload that repeats the image’s srcset as imagesrcset and its sizes as imagesizes, character for character, so the browser picks the same candidate twice and downloads it once. If the sizes of the image is wrong in the first place, fix it first: our srcset and sizes guide explains how.

HTML
<link rel="preload" as="image" fetchpriority="high"
      imagesrcset="/uploads/hero-480.webp 480w, /uploads/hero-960.webp 960w, /uploads/hero-1920.webp 1920w"
      imagesizes="100vw">

On the image itself. Remove loading="lazy", add fetchpriority="high", and keep its width and height.

Duplicated builder sections. The hidden variant should not download at all. A hidden image with loading="lazy" is never fetched; without it, it is, on every visit.

Check the result

  • Network panel, mobile emulation, cache disabled: the hero appears once, early, at the width you expect.
  • Same on desktop.
  • No “preloaded but not used” warning in either PageSpeed tab.
  • Several runs per device, compared by median, as explained in our guide on lab and field data.

With Mantys Core

With Mantys Core

Mantys Core can run your whole performance layer, cache included, or sit next to the setup you already have. For the LCP image, it measures instead of guessing:

  • The LCP image is recorded from real renders of each page, on mobile and on desktop, at the sizes the speed test uses.

  • When the two differ, it emits one preload per device; when they are the same, a single preload that reuses the image’s final srcset and sizes.

  • Preloads carry high fetch priority and are placed right after the viewport tag, ahead of the stylesheets.

  • Images above the fold are never lazy loaded.

The preload follows the page, page by page and device by device, without you maintaining a list of heroes.

In summary

  • The LCP element often differs between phone and desktop: check both.
  • A single preload makes one device download an image it does not show.
  • Use one preload per device, or one preload with the same srcset and sizes as the image.
  • Place it right after the viewport tag, and never lazy load the LCP image.
  • Verify in the network panel that the hero downloads once, on each device.

Comments

Stuck on a similar problem? Describe your setup and what you see. We read every comment and answer.

No comments yet. Be the first to share your case.

Comments are reviewed before publication. Your email is stored only to reply to you and can be deleted on request.

My AccountGet License →