Find which part of the largest element’s delivery is slow
Identify the largest visible content element and investigate what delays its appearance. Optimizing a small footer image will not address a slow hero image that dominates the initial view.
A large image can be slow because its request begins late, its transfer is heavy, the server is slow or rendering waits on other work. Compressing the file addresses only one possible cause. Identify the largest visible element and inspect its timing before selecting a fix.
A worked example
A hypothetical service hero is a 180 KB image but is discovered only after a script runs. Reducing it to 140 KB changes little if discovery remains the main delay. Another page uses an immediately discoverable multi-megabyte image and benefits from appropriate sizing and format.
How to apply it
- Identify the LCP element for the affected template and representative viewport.
- Separate server response, resource discovery, transfer and rendering delays in a trace.
- Apply the targeted change and repeat comparable tests without harming image clarity or page meaning.
What the result can establish
Use field evidence to assess the user experience where available, and preserve lab conditions for diagnosis. Do not replace a legible audit screenshot with an unreadable image just to reduce bytes. A speed change should retain the page’s useful content and conversion path.
Reference: web.dev: optimizing LCP.
Supporting documentation
web.dev: optimizing LCPGoogle: Core Web VitalsGoogle: technical requirements