A slow LCP should be treated as a chain: when was the LCP resource discovered, how long did the server take, how fast did the resource arrive, and what blocked it from being painted? That sequence tells you whether the useful change belongs to the image, server, CSS or font layer.
Identify the real LCP element
Capture the LCP element in the failing viewport and template. Do not optimise the hero image by habit if the measured LCP is a heading, poster frame or different responsive asset.
Measure server and discovery delay separately
A late HTML response delays everything; a fast response can still discover the LCP asset too late because it is injected by CSS/JS or missing preload priority.
Inspect resource transfer
Check dimensions, format, compression, responsive candidates and CDN delivery for images. For text LCP, verify font loading does not delay rendering unnecessarily.
Find render blocking after the bytes arrive
If the resource downloads early but paints late, inspect render-blocking CSS, font dependencies, client-side rendering or overlays that delay the final visible state.
Change the bottleneck, not every layer
Improving image compression will not solve a 1.5-second server delay; buying faster hosting will not fix an LCP asset discovered after JavaScript hydration. Rank the components by measured contribution.
Validate on representative templates
Retest the affected page and related templates on mobile/desktop. Then use field LCP to confirm the improvement survives real network and device diversity.
For image-specific cases use the hero-image LCP guide; if bytes start late, compare with slow first-byte diagnosis.