Why Does My Speed Report Identify the Product Headline Instead of the Hero Photo as LCP?

Understand what the metric actually selects

Google's web.dev documentation defines LCP using the render time of the largest eligible content element visible in the viewport. Eligible content includes images, text blocks and certain video presentations.

The browser considers the visible size of an element, not simply its importance in the merchandising design. A large headline may therefore become the reported LCP candidate even when the page contains a product photograph.

Do not assume that a hero image must always be LCP. The image may be smaller, partly outside the viewport, clipped, or excluded by a contentfulness heuristic. The actual browser and layout determine which candidates qualify.

Also distinguish an early candidate from the final reported candidate. As the page renders, a later and larger eligible element can replace an earlier one. A text block may initially qualify before the hero image becomes visible.

Inspect the element and its timing

Open the relevant performance report or browser trace and identify the LCP element itself. Record its selector, visible area, render time and the tested viewport.

If the element is the product headline, inspect its font-loading and rendering behavior. A web font can delay when text becomes visible, depending on the actual font-display behavior and browser rendering state.

If the reported element is an image, inspect request discovery, transfer, decoding and rendering. The appropriate intervention depends on where the delay occurs.

Do not diagnose from a single overall LCP number. A slower result after a design revision could reflect a different candidate element, not merely a slower download of the same photograph.

Use consistent test conditions. Mobile and desktop layouts may produce different LCP candidates because their visible areas and typography differ.

Choose the correction that matches the bottleneck

When the headline is the final LCP element and its font is delayed, investigate the documented font delivery and rendering route. Changing the product image's compression may have little effect on that text-rendering problem.

When the image becomes the final LCP candidate but arrives late, investigate its loading role, resource discovery and selected rendition. Avoid adding image preload hints simply because the page contains a large photograph.

If a hero image is intentionally below the initial viewport on mobile, its loading role may differ from desktop. Preserve the actual design and buyer task rather than moving content solely to force a particular metric element.

Compare the same page before and after one targeted change. Record both the identity of the LCP element and its timing. An improved number without a usable product page is not sufficient approval.

Hypothetical case: a large product headline

Hypothetical browser trace; no performance measurement was performed. A fictional store shows a large headline above a smaller bottle image on mobile.

Candidate A's stipulated report identifies the headline as final LCP. The developer initially proposes compressing the bottle photograph. That intervention is not supported by the reported element alone.

Candidate B investigates the headline's font-rendering timeline while retaining the same approved copy and image. B is the focused diagnostic candidate.

On a wider desktop layout, candidate C may instead report the larger bottle photograph as LCP. Its loading route requires separate investigation. The difference between B and C is a change in layout and candidate identity, not proof that one device has a defective image.

Record your own observations

The filled rows are illustrative examples. Use the blank row for your own files and observations.

Download the editable CSV worksheet

What the references establish

• web.dev — Largest Contentful Paint: Primary documentation for eligible LCP elements, visible-size calculation, candidate changes and rendering behavior.
• web.dev — Optimize Largest Contentful Paint: Provides a diagnostic framework for distinguishing LCP resource loading and rendering delays.