Tutorial · images · Published 2026-08-16 · 3 min read
Preload the hero image
Preload the hero image for a faster LCP, and learn when fetchpriority or font preload beats an image link preload.
The single biggest LCP win on a content page is making the hero image start downloading before the CSS and JavaScript finishes parsing. A normal <img> is discovered in order; a link rel="preload" in the head starts the fetch earlier, and where the hero is a CSS background-image, preload is the only way to start it before the stylesheet.
Why preload wins
The browser discovers an <img> during parsing, after the stylesheet and script nodes that precede it. On a rich page, the hero can lose 300 to 900 ms before its GET starts. A preload hint in the <head> declares the hero first, so the request fires in parallel with the HTML itself.
| Setup | First hero bytes start |
|---|---|
Plain <img> after styles/scripts | After the break in the stream |
link rel="preload" in head | At the discovery of the link node |
CSS background-image + no preload | After the stylesheet arrives |
The LCP candidate rules
Google scores the LCP of the largest visible image. For the hero:
- Preload exactly one image with the
imagetype and theas="image"hint, the LCP image, not three. - Make sure the preloaded URL is the one the browser will actually use. If your responsive
srcsetpicks a 800px variant but you preloaded the 1200px original, the browser downloads the wrong weight and LCP does not move. - Preload the same URL your
srcsetwould choose on the widest common viewport, or useimagesrcsetto preload with matching sizes.
<link rel="preload" as="image" href="/hero-1600.webp"
imagesrcset="/hero-1600.webp 1600w, /hero-800.webp 800w"
imagesizes="(max-width: 900px) 100vw, 1600px">The exceptions
fetchpriority="high"on a same-page<img>is the modern replacement for apreloadscan; it raises the priority without an extra request. Use it when theimgis in the initial HTML and needs no early download.- If the hero is decorative and LCP is not image-led (a text block wins), preloading an image just burns bandwidth. Let the LCP be the text.
<img fetchpriority="high" decoding="async"
src="hero-1600.webp"
width="1600" height="900" alt="Example hero">- Never preload an image you are not sure the page will use on this viewport (a mobile-specific hero that only renders on desktop) or every visitor pays for the wrong asset.
Measure before and after
Test with a WebPageTest or Lighthouse run on a throttled mobile profile, then A/B the preload:
- Record LCP with and without the
link preload. - If LCP does not move, look at what the browser actually requested: the start time of the hero request tells the story.
- When a preload helps, the image load no longer sits at the end of the critical waterfall; the same critical rendering path order starts with the hero.
When to involve a professional
If preloading the hero moved the LCP line but the whole page still fails the metric because other images or fonts preload before it (pushing the hero request down the queue), you have a priority-order puzzle, not a one-line fix. A performance engineer can reorder the head and value the fetchpriority matrix across pages.