Optimising the hero image for speed

The hero is the LCP element

On almost every landing page, the hero image is the Largest Contentful Paint (LCP) element: the largest block of visible content above the fold. LCP is good at 2.5 seconds and poor above 4.0 seconds, so the hero decides the lab score friends can see in Lighthouse and the field score real users experience. Every optimisation below assumes the hero must load like it is the one thing the page waits for.

Optimise the file itself

Three attributes control the raw download cost before any caching:

1. Format: the hero is a photo; deliver it as WebP or AVIF with a JPEG fallback. The WebP and AVIF reference shows expected savings of 25 to 35 percent over JPEG.
2. Size: render the hero at the largest size the layout uses, multiplied by the device pixel ratio. A 400px-wide hero column on a phone needs about an 800px file, not the 4000px original.
3. Compression: quality 75 to 85 with no visible artefacts. A hero over about 300 KB should raise a flag; see image compression to bring it down.

Never lazy-load the hero. loading="lazy" on the LCP element delays its fetch until the viewport is near, which can double the LCP. Keep it eager and above the fold.

Optimise the markup

<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">
<img
  src="/hero.webp"
  width="1600"
  height="900"
  alt="Hikers on a foggy ridge"
  fetchpriority="high"
  decoding="async"
  srcset="/hero-900.webp 900w, /hero-1400.webp 1400w, /hero-1600.webp 1600w"
  sizes="(min-width: 1024px) 50vw, 100vw"
>

• fetchpriority="high" on the image and on a preload link in the head raises the priority so the hero starts downloading before most other resources.
• sizes tells the browser which srcset candidate matches the layout; a 50vw hero on desktop gets the 1400w candidate, a phone gets the 900w one (see the srcset semantics guide).
• width and height reserve the box and fix CLS, and decoding="async" lets paint continue while the decode runs.

When it is not a photo

If the hero is a div with a CSS background, normal image loading does not apply: the browser lazily fetches background images unless you hint with a preload. Modern browser support for image-set() in preload varies, so a background hero is usually better replaced by an img (or a duplicate hidden <img> for the LCP). The background image LCP troubleshooting covers the trade-offs.

Verify

After applying the checklist:

1. Run Lighthouse and confirm the hero is listed as the LCP element and its timing sank under 2.5 seconds.
2. Confirm no lazy loading on the hero in the HTML.
3. Re-serve from cache so the preloaded URL, the src, and the srcset candidate all resolve, otherwise the preload is wasted.

The hero is the safest single change on a marketing page: format, size, compression, preload, and let the LCP optimisation guide the rest of the slow legs (server time, render blocking).