A WordPress hero image can download twice when its preload points to one file but the rendered image selects another. Compare the exact URLs and request initiators before blaming the CDN. A desktop preload and a smaller mobile srcset candidate can both be valid files while only one is needed for that visitor.
Prove which requests represent duplicate work
Open Network before a cold page load and filter by the hero filename. Record request URL, transfer size, initiator and timing. Do not count two rows as two full downloads without checking cache and transfer information. Redirects, cached responses and different page elements can make the list misleading.
Inspect the actual hero element's selected source. In developer tools, select that image and compare its currentSrc with the preload URL in the document head. Also inspect response Link headers if the host or optimization service injects resource hints outside the HTML.
| Mismatch |
Likely owner |
| Original JPEG preloaded, WebP rendered |
Image optimization and preload configuration disagree |
| Desktop source preloaded on mobile |
Responsive selection missing from the hint |
| Two image formats preloaded |
Multiple hints compete despite one rendered choice |
| Same image becomes a CSS background too |
Theme markup or breakpoint visibility rule |
Remove stale hints before adding new ones
Work on a staging copy and identify the component that owns the hint: theme, performance plugin, header snippet or host. Change one owner at a time. Do not add a third preload to compensate for two incorrect ones.
The responsive preload guide explains that HTML image preloads can use imagesrcset and imagesizes to match responsive selection. It also warns that preloading multiple supported formats can fetch all of them, unlike a picture element's first matching source. Prefer normal early HTML discovery when it already serves the critical image well.
Narrow view: Correct mobile candidate. Wide view: Correct desktop candidate. Transfer: No unnecessary second file. Outcome: Measure LCP separately. Explanatory checklist, not a customer test result.
Use a before-and-after evidence sheet
For each tested viewport, record the chosen image URL, number of transferred hero candidates, total image bytes and the measured LCP element. Keep the device scale and cache conditions consistent. A visual screenshot alone cannot show whether the browser fetched an unused file.
Check at least one narrow and one wide viewport. If the theme uses art-directed crops, verify the correct composition rather than forcing every screen to use the same desktop image. Confirm that the visible hero is not still delayed behind JavaScript or lazy loading.
An example diagnosis might be: the performance plugin preloads a full-size original, while the image CDN rewrites the visible image to a width-specific derivative. The repair should align the actual delivery path or remove the redundant hint. It should not disable responsive images throughout the site.
Measure the outcome honestly
Repeat several comparable traces after the cache has been rebuilt. Reduced duplicate transfer is useful, but it does not guarantee a specific LCP improvement if server response or rendering delay dominates. Field reports also take time to reflect changed visitor experiences.
Continue with the mobile LCP investigation if the page remains slow. HandL WP can review the theme and optimization interaction while preserving mobile image quality and the intended first-screen layout.
References reviewed October 12, 2026. Examples are explanatory, not customer test results.