CSS background images sit behind a discovery disadvantage that <img> elements don’t have: the browser can’t find them until it has downloaded and parsed the CSS that references them, because unlike an <img src> in the HTML, a background image is invisible to the preload scanner that normally finds image resources early by scanning raw HTML before full parsing and rendering. That delay in discovery, not any inherent exclusion from LCP eligibility, is usually what causes background images to become the LCP bottleneck. The practical fix has two layers: preload the actual image resource explicitly, with the correct responsive variant, so discovery no longer waits on CSS; and where the image is genuinely the largest content element, prefer an <img> element over a pure CSS background, since Chrome’s LCP candidate detection and loading prioritization behavior is more consistent and better supported for image elements than for CSS backgrounds.
Mechanism
Chrome’s LCP algorithm considers <img> elements, <image> elements inside SVG, poster images on <video>, and elements with a CSS background-image applied, among its candidate types, so a CSS background image is not categorically excluded from being the LCP element. But being an eligible candidate and being discovered early are two different things. The browser’s preload scanner is a fast, HTML-only pass designed to find likely-important resources (images, scripts, stylesheets) before the main parser has finished, precisely so those resources can start downloading as early as possible. A CSS background-image reference lives inside a stylesheet or a <style> block, so the preload scanner can’t see it; the browser has to first fetch and parse the CSS, then compute layout enough to know the element exists and is visible, before it even knows the background image needs to be requested at all. On a responsive layout, this gets worse if the background is set via a media query or is computed from multiple candidate sources, since resolving which image actually applies requires even more of the rendering pipeline to complete first.
The net effect is a request that starts much later than it would if the same image were referenced directly in HTML, and Chrome’s default resource-priority behavior compounds this: images in the viewport typically start at a lower fetch priority and only get upgraded once the browser has completed enough layout to confirm they’re visible and above the fold, which again requires CSS to have been processed. An <img> element, by contrast, is visible to the preload scanner immediately in the raw HTML markup and can begin fetching before CSS or layout are involved at all.
Practical strategy
The most direct fix is an explicit preload hint for the actual image resource, which sidesteps the CSS-discovery delay by declaring the resource in HTML where the preload scanner can see it immediately:
<link rel="preload" as="image" href="/hero-bg-800.webp"
imagesrcset="/hero-bg-480.webp 480w, /hero-bg-800.webp 800w, /hero-bg-1600.webp 1600w"
imagesizes="100vw"
fetchpriority="high">The imagesrcset/imagesizes pair matters specifically for responsive layouts, because a plain href preload only tells the browser about one file; without the srcset-equivalent hints, the browser may preload a variant that doesn’t match what the CSS ultimately selects at the actual viewport width, which either wastes bandwidth on the wrong file or fails to actually accelerate the image the layout ends up using. fetchpriority="high" further ensures the browser doesn’t wait for the normal viewport-visibility-based priority upgrade before fetching it seriously.
Where the image is highly likely to be the LCP element (a full-bleed hero image, a large above-the-fold banner), the more robust strategy is to stop using a pure CSS background for it and use a real <img> element instead, visually positioned to fill the same role a background image would (using object-fit: cover, absolute or grid/flex positioning, and appropriate z-index layering to place other content over it). This gets automatic preload-scanner discovery without needing a manual preload tag, gets native srcset/sizes support for responsive variants without the extra imagesrcset syntax, and gets more consistent, better-tested LCP candidate detection, since Chrome’s handling of <img>-based LCP candidates has simply had more engineering attention and fewer edge-case inconsistencies over time than CSS-background LCP detection, particularly across responsive breakpoints and dynamically computed backgrounds.
This isn’t a claim that CSS background images can never be handled correctly for LCP, Chrome’s detection and prioritization behavior here has evolved over time and continues to improve, and a properly preloaded background image with correctly matched responsive variants can perform well. It’s a statement about default reliability: an <img>-based approach removes an entire category of discovery-timing failure modes by construction, while a CSS-background approach requires the developer to manually replicate what the browser would otherwise do automatically, and to keep that manual replication (the preload tag’s srcset variants) in sync with the CSS as the design changes. For a resource this critical to the page’s LCP score, removing manual-sync failure points is worth more than the layout convenience CSS backgrounds otherwise offer.
A hypothetical illustration of the discovery delay
Hypothetically, imagine a boutique hotel chain’s site, “Alderbrook Collective,” where the homepage hero uses a full-bleed CSS background image set via a media query for responsive breakpoints. A Lighthouse audit flags LCP as poor, and the initial assumption might be that the image itself is simply too large. Investigation could instead reveal the image file itself is reasonably sized and compressed, the actual delay is that the browser doesn’t even start requesting it until CSS has been fetched and parsed and layout has confirmed the element is visible, several render-blocking steps deep. Adding an explicit preload hint with matching responsive variants for the hero image, without changing the image file itself at all, would likely move the LCP score meaningfully just by letting the browser discover and start fetching the resource far earlier in the page’s loading sequence.
