PageSpeed Insights identifies the hero image as the Largest Contentful Paint element. The obvious response is to compress the file.
Compression may help, but it is only one part of the timeline. The browser must discover the image, choose a source, establish any required connection, download it, decode it and paint it. A reasonably small file can still appear late if WordPress or the theme hides its URL until JavaScript runs.
Repair the stage that is actually late.
Confirm that the same element is LCP consistently
Run several tests and record the reported element. Responsive layouts, cookie banners and sliders can change the candidate between runs.
In Chrome developer tools:
- open the Performance panel;
- record a clean page load;
- inspect the LCP marker;
- select the associated element;
- note when its request begins and ends.
If the LCP element changes, stabilise the layout and priority before comparing file sizes.
Break LCP into four useful parts
Think of the delay as:
- server response;
- resource discovery;
- resource download;
- rendering and decode.
If the HTML itself arrives after two seconds, image compression cannot recover that entire delay. If the HTML arrives quickly but the image request begins late, discovery is the stronger lead.
The Network waterfall should show both the main document and hero request on the same timeline.
Make the image discoverable in the initial HTML
The browser can prioritise an ordinary <img> it sees during HTML parsing:
<img
src="/uploads/service-hero-1280.webp"
width="1280"
height="720"
alt="WordPress performance diagnosis"
>A hero inserted as a CSS background may not be discovered until the stylesheet downloads and is parsed. A hero added by JavaScript waits even longer.
Do not convert every background image into content markup. Decorative imagery can remain in CSS. The primary visual that communicates page content is often better represented by an image element with meaningful alternative text.
Do not lazy-load the initial LCP image
Lazy loading is useful below the fold. On the first visible hero it can delay the request.
Check the rendered HTML, not only the WordPress editor. The initial hero should normally avoid loading="lazy". WordPress has logic intended to handle loading attributes, but themes, builders and optimisation plugins can override it.
A deliberate hero may use:
<img
src="/uploads/service-hero-1280.webp"
width="1280"
height="720"
loading="eager"
fetchpriority="high"
alt="WordPress performance diagnosis"
>Do not add fetchpriority="high" to several images. If everything is high priority, the browser has no useful prioritisation signal.
Check which responsive source the browser selects
The displayed hero might be 700 pixels wide while the browser downloads a 2400-pixel original.
Inspect the element’s currentSrc in the Console:
const hero = document.querySelector(".hero img");
console.log({
selected: hero?.currentSrc,
renderedWidth: hero?.getBoundingClientRect().width,
intrinsicWidth: hero?.naturalWidth
});Run this only as a read-only diagnostic. Replace .hero img with a selector verified on your page.
If intrinsic width is far beyond what the layout and screen density require, review srcset and sizes.
Correct sizes before generating more files
An image can have a complete srcset and still choose a large candidate because sizes describes the layout incorrectly.
For a full-width mobile hero limited on desktop:
sizes="(max-width: 767px) 100vw, 1200px"This is an example, not a universal value. Account for container padding, columns and the real maximum width.
Test common viewports and high-density screens. The browser may reasonably choose a source wider than the CSS box to support device pixel ratio.
Compress to a visual target, not an arbitrary percentage
Start from the rendered dimensions and content:
- photography tolerates lossy compression;
- logos and interface captures may need sharper edges;
- transparent artwork may not suit JPEG;
- gradients can band at aggressive quality;
- text embedded in an image deserves special care.
Compare the output at actual display size on desktop and mobile. A smaller file that damages the first impression is not automatically better.
Remove unnecessary metadata, but preserve any metadata the business is required to retain.
Check server and CDN delivery of the image itself
The HTML can be fast while the image origin is slow. Select the hero request and inspect waiting time, status, redirects and cache headers.
A common failure is an image URL that redirects from HTTP to HTTPS, then to a CDN or resized variant. Each step delays the download. Another is a CDN that never caches the hero because the response has unsuitable headers or changing query parameters.
Verify the final request directly:
curl -I https://example.com/uploads/service-hero-1280.webpConfirm one successful response, the expected Content-Type, a deliberate cache policy and no avoidable redirect. Do not give mutable image URLs an immutable cache lifetime unless changes produce a new URL.
If the image is generated dynamically on first request, measure the cold and cached paths. A resizing service should not make the first real visitor wait for expensive processing without an agreed warming or generation strategy.
WebP or AVIF does not guarantee a good result
Modern formats can reduce file size, but conversion settings and source characteristics matter. A poorly configured WebP can be larger than a well-compressed JPEG. AVIF encoding can be slow and may soften details at low quality.
Measure the bytes actually delivered by the browser. Keep a fallback where the delivery stack requires it and verify Content-Type.
Do not create several formats if the server or plugin cannot select them reliably.
Preload only when discovery is genuinely late
If the hero remains a CSS background or is otherwise discovered late, a preload can expose it earlier:
<link
rel="preload"
as="image"
href="/uploads/service-hero-1280.webp"
fetchpriority="high"
>Responsive preloads require more care because the preload must match the source the image later uses. A mismatched preload can download one file and then fetch another.
After adding a preload, verify in the Network panel that it is used and does not compete with critical CSS or fonts.
Reserve dimensions to prevent layout movement
Width and height attributes allow the browser to calculate an aspect ratio before the image arrives. CSS can still make the image responsive:
.hero img {
display: block;
height: auto;
max-width: 100%;
}If the mobile and desktop crops use different aspect ratios, use <picture> with correct dimensions or reserve space through CSS. Avoid a large empty box that later changes shape.
Sliders make LCP harder to control
A hero slider may download several images, initialise JavaScript and replace the initial slide. The reported LCP can move between slides.
Ask whether the slider produces business value. If it remains:
- render the first slide in HTML;
- prioritise only its image;
- delay non-visible slides;
- preserve dimensions;
- ensure controls work without blocking.
Do not preload every slide.
Verify the entire first view after the change
Retest:
- clean mobile load;
- desktop load;
- cache hit and miss;
- consent states;
- navigation and CTA;
- visual quality;
- LCP element and timing;
- layout shift.
An earlier hero is not a successful repair if text, menu or form functionality regresses.
Evidence for an LCP image assessment
Provide the URL, PageSpeed result, reported element, device mode and any recent image/theme changes. A waterfall or screenshot of the element is useful. Initial assessment does not require credentials.
If a WordPress hero image delays LCP, we can identify whether time is lost in server response, discovery, download or rendering. The repair will target that stage and preserve visual quality, layout and conversion.