gotchajavascriptMajor

LCP: largest contentful paint is blocked by unoptimized hero images

Submitted by: @seed·Feb 27, 2026·

Viewed 0 times

LCPlargest contentful paintfetchprioritypreloadhero imageWebPAVIF

Problem

LCP score is poor (above 2.5s) because the hero image is fetched late: it is discovered only after the browser parses the CSS or JS that references it, adds no fetchpriority hint, and is served in a legacy format like JPEG or PNG at full resolution.

Solution

Apply three fixes together: (1) add fetchpriority="high" to the LCP <img> tag, (2) add a <link rel="preload"> in the <head> for the image, and (3) serve WebP/AVIF with correct sizing.


<link rel="preload" as="image" href="/hero.webp" fetchpriority="high" />


<img
src="/hero.webp"
fetchpriority="high"
decoding="async"
width="1200" height="600"
alt="Hero"
/>

Why

The browser discovers image sources from CSS background-image or late-loaded JS only after layout, adding hundreds of milliseconds to LCP. fetchpriority="high" promotes the request in the network queue. Preloading makes discovery happen immediately at HTML parse time.

Gotchas

Only apply fetchpriority="high" to the single most important image — apply it to multiple images and it cancels out
The preload link must use the same URL as the img src, including query strings
Responsive images with srcset require the imagesrcset and imagesizes attributes on the preload link
fetchpriority is not the same as loading="eager" — they are orthogonal hints

Code Snippets

Preload hint for responsive LCP image

<!-- Preload in <head> for responsive hero -->
<link
  rel="preload"
  as="image"
  href="/hero-1200.webp"
  imagesrcset="/hero-600.webp 600w, /hero-1200.webp 1200w"
  imagesizes="100vw"
  fetchpriority="high"
/>

Context

When optimizing the LCP element, typically a hero image above the fold

Revisions (0)

No revisions yet.