Diagnose a hero image that starts loading too late

Find the element rather than guessing from the design

Use a performance report and trace for the affected page and device. Record which image or text element actually becomes LCP. A desktop banner may not be the same element on mobile. Capture URL, viewport, test conditions, and page version so the developer is investigating a reproducible case rather than the largest file in the media library.

Source checks: web.dev: Optimize Largest Contentful Paint · Google Developers: PageSpeed Insights data

Read the resource's start time

Inspect the resource request in the network timeline. Compare when the page response arrives, when the relevant image request begins, and when it completes. A long delay before requesting a small image calls for a different repair from a large image that starts promptly but downloads slowly. Keep both timings in the brief.

Check discovery and lazy loading

Review whether the image URL appears in initial HTML or is introduced later by script or CSS. Ask whether a likely above-the-fold LCP image has a lazy-loading instruction. web.dev recommends making the resource discoverable early and not lazy-loading the LCP image. Do not apply the same high priority to every gallery photo.

Try one targeted loading change

Keep the important visitor content intact.

• Expose the likely LCP resource through supported initial markup or a justified preload.
• Remove inappropriate lazy loading from the likely LCP image.
• Use selective priority hints only where the identified resource warrants them.
• Check responsive image selection so mobile does not download an unsuitable asset.
• Repeat comparable tests and inspect actual request timing.
• Verify layout and image quality alongside the metric.

Avoid preload saturation and score chasing

Several high-priority preloads can compete with the resource you intended to help. A fast synthetic result is not proof that every visitor sees the same timing. Compression may still matter, but it does not erase discovery delays caused by a script or hidden source. Keep the repair tied to the traced bottleneck rather than a general replace-all-images request.

Report the evidence and later user experience

Save before-and-after traces with matched settings. Report the resource-start change, the observed LCP timing, and any tradeoff such as extra downloads. Review field data over its collection window when enough data exists. A single run or performance-score change is not a measured change in inquiries or rankings.

For a shared hero component, check a second service page and a mobile layout with a different image. Document which resource is intentionally prioritized. If editors can replace the hero later, include size, responsive delivery, and loading behavior in the media brief so the same delayed discovery does not return during routine content updates.

Illustrative small image with a late request

In an illustrative trace, HTML arrives at 0.4 seconds, but a 70 KB hero image is not requested until 1.6 seconds because a slider script inserts it. The editor exposes the initial visible image early and repeats the same test. The example diagnoses request delay; its timings are sample inputs, not measured Getting Found Local client results.

The trace note keeps the image's discovery gap separate from download duration. The developer can then test whether exposing the URL earlier changes the gap before deciding whether further compression or rendering work is needed.

Questions about this task