Optimized Background Images: Best Practices for SEO and Speed

This check looks at images loaded through CSS background-image — hero banners, section backdrops, decorative panels — and flags when they're oversized, uncompressed, or served in dated formats. It matters because a bloated background often is your Largest Contentful Paint element, and a slow LCP drags down both your Core Web Vitals and the rankings tied to them.

Why background images are a blind spot

Background images don't live in the HTML as <img> tags, so they slip past the usual image checks and the browser's normal preload scanner. The browser can't even discover them until it has parsed the CSS that references them, which pushes the download later and can delay your largest paint. On top of that, backgrounds tend to be the biggest visuals on the page — full-width hero shots — and they're the ones people most often forget to compress. A 2 MB unoptimized hero can single-handedly blow your mobile LCP budget.

A real failing example

A raw multi-megabyte JPEG, one size for every device, discovered late by the browser:

.hero {
  background-image: url("hero-photo.jpg"); /* 2.4 MB, 4000px wide */
  background-size: cover;
}

Compress it, ship a modern format with a fallback, and give the browser a head start with a preload hint:

/* Modern format with fallback via image-set() */
.hero {
  background-image: url("hero-photo.jpg"); /* fallback */
  background-image: image-set(
    "hero-photo.avif" type("image/avif"),
    "hero-photo.webp" type("image/webp"),
    "hero-photo.jpg"  type("image/jpeg")
  );
  background-size: cover;
}

<!-- Let the browser fetch the LCP background early -->
<link rel="preload" as="image" href="hero-photo.avif"
      type="image/avif" fetchpriority="high">

Same visual, a fraction of the bytes, and it starts downloading sooner instead of waiting on the CSS.

Background image vs. <img>: pick the right tool

Rule of thumb: if the image carries meaning, it should be an <img> with alt text. Reserve backgrounds for genuinely decorative visuals.

How to detect it on your own site

1. Run PageSpeed Insights or Lighthouse. Check "Properly size images," "Efficiently encode images," and "Serve images in next-gen formats." If the LCP element is a background, the report names it directly.
2. Watch the Network panel. Open DevTools → Network → filter to Img, reload, and sort by size. Any background over a few hundred KB on mobile is a candidate. The waterfall also shows how late it started.
3. Confirm the LCP element. In Lighthouse's diagnostics or the Performance panel, check whether your LCP is a background image. If it is, that's your top priority.
4. Audit the CSS. Search your stylesheets for background-image: and background: shorthand with a url(). That list is every candidate; cross-reference each file's weight and format.

How to fix it

1. Compress hard. Run every background through a compressor. Hero photos can usually shed 60–80% with no visible loss.
2. Serve AVIF or WebP. Use image-set() with a JPEG fallback so modern browsers get the smaller file. See Serve Images in Next-Gen Formats.
3. Ship device-appropriate sizes. Don't send a 4000px desktop hero to a 400px phone. Swap smaller files via media queries in your CSS.
4. Preload the LCP background. Add a <link rel="preload" as="image"> with fetchpriority="high" so the browser doesn't wait for the CSS to discover it.
5. Don't lazy-load the above-the-fold hero. Deferring your LCP image makes LCP worse. Lazy-loading is for offscreen images — see Defer Offscreen Images.
6. Re-test. Re-run PageSpeed and confirm LCP improved and the image warnings cleared.

FAQ

Do background images even count toward Core Web Vitals?

Absolutely. A CSS background can be your Largest Contentful Paint element, and LCP is a Core Web Vital that feeds page-experience signals. An unoptimized background is one of the most common reasons mobile LCP fails. Our LCP guide walks through the full chain.

Should I use a background image or an <img> tag?

If the image means something — a product shot, a photo people should perceive — use <img> so it gets alt text, native lazy-loading, and early discovery. Reserve background-image for decoration. The table above lays out the trade-offs.

Can I lazy-load a background image?

CSS backgrounds have no native loading="lazy", and you shouldn't lazy-load an above-the-fold hero regardless — that delays LCP. For offscreen decorative backgrounds you can defer with an Intersection Observer, but the win is small compared with just compressing the file.

Why is my background image discovered so late?

The browser's preload scanner reads HTML and can fetch <img> sources immediately, but a background isn't known until the CSS that references it has been downloaded and parsed. That's the discovery delay a preload hint is designed to erase.

What format should background images be in?

AVIF first, WebP as the fallback, and a JPEG or PNG as the final fallback for old browsers. image-set() lets the browser pick the best one it supports. AVIF typically beats JPEG by a wide margin at the same visual quality.