A likely main image is not discoverable from the HTML

Why it matters

web.dev's guide to optimising Largest Contentful Paint explains that the browser can start downloading an image named in the initial HTML as soon as it scans the document, whereas an image named only in CSS waits until the stylesheet has been fetched and applied. For an image used that way, the guide recommends a preload so the download can begin earlier.

What to do

1. Open the finding: it shows the element, its declared size and position in the main region, the words before it, the CSS rule that sets its background with stylesheet and position, and the resolved image address.
2. Check in a browser whether this image is the main picture people see when the page opens.
3. If it is, show it with an ordinary <img> whose src is that address, or add <link rel="preload" as="image" href="…"> with the same address to the page's <head>.
4. fetchpriority="high" or a preconnect may help further, but neither is required by this check and neither makes the image discoverable on its own.

When to leave it as it is: If the reported element is not the first large thing people see, for example because a slider or other content appears before it, or the background is purely decorative, you can leave it.

What we read

We read the complete original HTML of pages that returned 200 and appear to be rendered on the server, in the same HTML5 tree a browser's parser builds, together with the styles the page applies: linked stylesheets, <style> blocks, their @import files and inline style attributes. Nothing is rendered and no JavaScript runs.

The page needs one clear main region: the <main> element; if there is none, an element whose role contains the main token; if there is none, an <article>. If the first of these that exists appears more than once, or none exists, the page is not checked.

In the main region, in document order, we take the first <img> or element with a CSS background image whose declared size, from HTML attributes or CSS, is at least 600 × 300 pixels. Smaller ones are skipped. If more than 200 words of the main region come before it, the rule does not apply; if it is an <img> with a readable source, the page passes.

For a background, we resolve its address against the stylesheet's own address and look for the same address in an ordinary <img> anywhere on the page, or in a <link rel="preload" as="image"> inside <head> that applies to screens. The page is reported when neither exists. A srcset or imagesrcset listing several files, a preload outside <head> or one with an unresolved media condition cannot confirm a match, and leaves the page not checked when it might be the one. A <picture> with unresolved <source srcset> alternatives cannot prove that its fallback image address matches. A CSS import layer also leaves sizing unconfirmed.

An earlier image or background whose size, visibility or address cannot be resolved, hidden or conditionally shown content before the candidate, or unsupported CSS leaves the page not checked.

Example & evidence

Illustrative example — schematic HTML and CSS, not a live audit.

The page https://bakery.example/ links /assets/site.css, which contains this rule:

.hero {
  width: 1200px;
  height: 400px;
  background-image: url("/img/hero.jpg");
}

<main>
  <div class="hero"></div>
  <h1>Fresh bread every morning</h1>
</main>

The first large element in the main region is a 1200 × 400 background whose image is named only in the CSS, so the page is reported.

<link rel="preload" as="image" href="/img/hero.jpg">

A possible correction: add this preload to the page's <head>, or show the picture with an <img> whose src is /img/hero.jpg. The next full audit confirms the fix when it reads the same page and its CSS in full and finds the address in the HTML; if no qualified candidate or main region remains, the earlier problem stays unconfirmed.

Confirm & check again

Check for yourself: record a page load in the Performance panel of Chrome's developer tools to see which element it marks as the Largest Contentful Paint, and check in the Network panel whether that image starts downloading only after the stylesheet.

Check again: Full audit — run a new full audit of the site. The finding is confirmed fixed only when the same page is read in full with all of its stylesheets and its first large main-region image is now an <img>, or its address appears in an ordinary <img> or a matching image preload in the head. If no qualified candidate or main region remains, or a stylesheet or relevant declaration cannot be read, the finding stays unconfirmed.

Limits & sources

The 600 × 300 size and the 200-word position are fixed rules of this check, not viewport or LCP thresholds. We do not render the page, identify the real Largest Contentful Paint element or measure when the image downloads, and adding a preload does not by itself prove a faster page. Only declared sizes are used: an element sized by its content, unsupported CSS and anything a script adds cannot be read and can leave the page not checked. Response-header preloads and browser-selected picture alternatives are not confirmed by this HTML check.

Confidence: Low because declared sizes and word positions only suggest which image people see first; a browser may paint a different element first, and loading is not measured.

Sources

• web.dev, Optimize Largest Contentful Paint — explains that an LCP image named in the initial HTML can be found by the browser's preload scanner, while one referenced only from CSS waits for the stylesheet, and recommends preloading such an image. Checked 10 October 2026.

Editorial review: 2 November 2026