Above the fold, visitors wait for a visible result rather than an average of every image on the page. A large header photograph may be the LCP element. The browser needs to discover it early, receive the right-sized file and avoid unnecessary competition from other requests.
Locate the key image
Inspect the mobile page and the Largest Contentful Paint element in PageSpeed Insights. The delay may come from a large file, late discovery in HTML or a slow server response.
Do not choose the culprit by looking only at the largest file on disk. Open a report for the exact URL and device, identify the LCP element and find its request in the network waterfall. Note when the browser discovered the URL, when the download began and how many bytes arrived. If LCP is a text block, changing a nearby photograph may have little effect on that metric.
Fix the obvious mismatch
Compare the image dimensions with how large it appears. If a small card downloads a huge original, review srcset and theme markup. Compress or convert the selected variant after confirming its visual quality.
Compare the displayed width with the downloaded image dimensions. If a narrow card fetches a huge original, review the theme output, srcset and sizes before converting the file. Then optimize the specific candidate the browser selected. Compressing a different WordPress thumbnail can produce an attractive plugin report without changing what visitors download.
Three reasons a hero can be slow
- Excess pixelsInspect the dimensions of the file actually downloaded.
- A late requestSee when the browser first discovers the image URL.
- Another bottleneckCompare LCP with server time and blocking resources.
Avoid delaying a hero image
An image needed on the first screen should normally not be lazy-loaded. Inspect the final HTML because themes and plugins can alter loading attributes. loading="lazy" and fetchpriority="high" on the same image pull in opposite directions.
An image visible without scrolling should usually be discoverable early. Check whether its URL is present in the initial HTML or appears only after a script runs. A CSS background may need different treatment from an ordinary img element. Avoid applying lazy loading to the critical first-screen image by habit; keep that technique for content farther down the page and measure the result.
Measure again
Repeat the check on the same URL and device type. Compare actual transfer size, request start time and LCP. If nothing changes, inspect CSS, scripts, server time and CDN cache.
Repeat measurements on the same URL and device type under comparable conditions. Several runs are more useful than one unusually fast or slow result. If transferred bytes fall but LCP barely moves, inspect server response time, render-blocking styles and the start of the image request. That evidence points to the next change instead of another blind compression pass.
A practical example
Imagine a banner that is already compressed but only starts downloading after a long JavaScript chain. Another round of compression may barely help, while making the image discoverable in the initial HTML could matter more. Inspect the request waterfall and measured LCP before changing loading attributes.
Before you publish
- Make sure the key image is not lazy-loaded without a good reason.
- Inspect transferred bytes and when its request starts.
- Repeat the measurement on the same URL and device after clearing caches.
Explore more
Check the result on your own website and keep an original when you may need to restore it.