How Images Affect LCP

Largest Contentful Paint measures when the main visible content appears. On modern pages, that content is often an image: a hero, product photo, article cover, or large promo card. If that image is heavy or discovered late, LCP suffers.

Why images slow LCP

Image LCP problems usually come from five causes:

1. The file is too large.
2. The dimensions are far bigger than the display size.
3. The browser discovers the image too late.
4. The image is lazy-loaded even though it is above the fold.
5. The responsive markup makes the browser choose the wrong candidate.

The batch image compressor helps with the first two. Your template handles discovery and priority.

What a good LCP image needs

For photo heroes, test AVIF in the AVIF compressor and keep WebP fallback.

Good hero markup

<img
  src="/hero.webp"
  srcset="/hero-960.webp 960w, /hero-1600.webp 1600w"
  sizes="100vw"
  width="1600"
  height="900"
  alt="Descriptive alt text"
  fetchpriority="high"
/>

The LCP timeline in plain English

For an image to become visible, the browser has to discover the URL, request it, download the bytes, decode the image, and paint it. A delay at any point can hurt LCP. That is why image optimization is not only about compression.

If the image URL is hidden inside late JavaScript, discovery is late. If the file is a 2MB JPEG, download is slow. If the dimensions are missing, layout may shift. If the image is lazy-loaded, the browser may intentionally wait before requesting the most important visual on the page.

Background images are a common trap

CSS background images can be fine for decorative art, but they are often worse for LCP heroes because the browser discovers them after CSS arrives and is parsed. If the image is meaningful content, prefer an actual <img> or <picture>. It gives you alt text, dimensions, priority hints, and responsive candidates.

If design requires a background-like treatment, you can still use an absolutely positioned image element behind content. That keeps the performance benefits while preserving the visual layout.

Compression is only the first fix

A smaller image helps most when the image was transfer-bound. But sometimes the real problem is server delay, render-blocking CSS, a late client-side render, or a wrong sizes attribute that makes the browser download a huge candidate. Fixing LCP means reading the waterfall, not guessing.

Use this sequence:

1. Confirm the LCP element.
2. Check when the image request starts.
3. Check file size and dimensions.
4. Check whether the chosen srcset candidate is reasonable.
5. Check cache and CDN behavior.
6. Retest on mobile.

What “good enough” looks like

For many pages, the LCP image should be discovered in the initial HTML, requested early, sized close to the rendered need, and delivered in a modern format. It should not wait for a carousel script, an animation library, or a client-only component to mount.

The exact file size depends on design. A simple hero can be under 150KB. A rich product image may justify more. The important thing is that every byte has a visual reason to exist.

Related image metrics

LCP gets the headline, but images also affect CLS and INP. Missing dimensions can cause layout shift. Huge images can consume decode time and compete with main-thread work. Overloaded galleries can make interaction feel sluggish on mid-range phones. Image performance is part of the whole page, not a single Lighthouse row.

For a repair workflow, read how to fix large image LCP. For a broader Core Web Vitals guide, read how to optimize images for Core Web Vitals and LCP.