Fix a Slow LCP: Get Your Hero Image to Load First

PageSpeed Insights gives your homepage a red Largest Contentful Paint score, and the report points at the big photo in your header. You compressed it, you installed a cache plugin, and the number barely moved.

LCP is not really an "image size" problem. It is a discovery and priority problem: the browser has to find out the image exists, decide it matters, and download it before anything else competes for bandwidth. This guide walks through the checks in the order that usually matters.

Step 1: Confirm which element is actually the LCP

Don't guess. Two ways to see it:

1. Run your page through PageSpeed Insights. Scroll to the diagnostics and open Largest Contentful Paint element. It names the exact HTML element.
2. Or in Chrome, press F12 → Performance tab → reload the page. In the timeline, find the LCP marker and hover it; DevTools highlights the element on the page.

Sometimes the LCP element is not an image at all — it can be a heading or a block of text, in which case fonts and CSS are your problem, not images. The rest of this article assumes it is an image.

Also note whether you are reading field data (real visitors, shown at the top of the PageSpeed report when enough data exists) or lab data (the simulated test below it). Lab data changes every run. Field data is what Google actually uses.

Step 2: Open the LCP breakdown

PageSpeed Insights splits LCP into four parts: time to first byte, resource load delay, resource load duration, and element render delay. Expand that section — it tells you which fix to apply.

• Large TTFB: the HTML itself is slow. Page caching and server-side issues, not image issues.
• Large load delay: the browser found the image late. This is the discovery problem — lazy loading, CSS background images, or a slider.
• Large load duration: the file is genuinely too big for the connection.
• Large render delay: something else (usually CSS or JavaScript) is blocking painting.

Step 3: Stop lazy-loading the image above the fold

This is the single most common cause. Lazy loading tells the browser "don't download this until it scrolls into view" — which is exactly wrong for an image that is visible immediately.

View the page source (Ctrl+U) and search for your hero image filename. If you see loading="lazy" on it, that is your bug.

WordPress 5.9 and later tries to skip lazy loading for the first image on a page, and WordPress 6.3 and later adds fetchpriority="high" to the image it thinks is the LCP candidate. But themes, page builders and cache plugins frequently output their own markup and override this.

If you use the LiteSpeed Cache plugin, go to LiteSpeed Cache → Page Optimization → Media Settings. If Lazy Load Images is on, add your hero image to the exclusion list. In current plugin versions the exclusion fields are on the Media Excludes tab (older versions keep them on the same page as the toggles). You can exclude by part of the filename or URL, one per line:

hero-banner
/wp-content/uploads/2026/01/homepage-top

Other cache and optimization plugins have an equivalent "exclude from lazy load" box. If yours doesn't, turn lazy loading off for a test run and re-measure to confirm the cause before hunting for a permanent fix.

Step 4: Make sure the image is discoverable in the HTML

The browser's preload scanner reads the raw HTML before CSS and JavaScript finish. It can only find images written as <img> tags. It cannot find:

• images set as a CSS background-image
• images inserted by JavaScript sliders and carousels
• images inside <picture> elements that depend on a JS polyfill

If your hero is a CSS background, the cheapest fix is to add a preload hint in the <head>, before your stylesheets:

<link rel="preload" as="image" href="https://example.com/wp-content/uploads/2026/01/hero.webp" fetchpriority="high">

In WordPress you can add this with a small snippet in your child theme's functions.php:

add_action( 'wp_head', function () {
    if ( ! is_front_page() ) {
        return;
    }
    echo '<link rel="preload" as="image" href="https://example.com/wp-content/uploads/2026/01/hero.webp" fetchpriority="high">' . "\n";
}, 1 );

Preload only one image. Preloading five things is the same as preloading nothing.

If the hero is inside a slider with four slides, the real fix is different: make the first slide a plain <img> in the HTML and let the slider script load the rest. Many slider plugins have a setting for this. If yours doesn't, consider replacing the slider with a static image — a carousel that nobody swipes is pure LCP cost.

Step 5: Serve a file that matches the display size

Now deal with the bytes. Two checks:

1. In DevTools, hover the image in the Elements panel. Chrome shows "Intrinsic size" (the file) and the rendered size. If the file is 2400px wide and it renders at 800px, you are shipping roughly nine times the pixels needed.
2. Check the format. WebP typically produces a smaller file than JPEG at comparable quality. Compare the two yourself with your own image before deciding.

Practical approach: resize and compress the image before uploading it, using a tool like Squoosh, then upload. That removes a plugin from the equation entirely. Export at roughly twice the widest size it will ever display, for high-density screens.

If you prefer automation, the LiteSpeed Cache plugin's Image Optimization feature handles compression and WebP generation through the QUIC.cloud service, which requires connecting a QUIC.cloud account. Other optimization plugins process images on your own server instead. Either way, keep the originals — check that your plugin stores backups before you run a bulk optimization.

Make sure srcset is present on the <img> tag so phones get a smaller file than desktops. WordPress adds it automatically to images inserted through the media library; hand-written theme markup often skips it.

Step 6: Clear render-blocking resources out of the way

If your LCP breakdown shows a big render delay, the image downloaded fine but the browser couldn't paint. Usual suspects: a large theme stylesheet, icon font libraries, and third-party scripts loaded in the <head>.

LiteSpeed Cache's Page Optimization → CSS Settings includes options such as Generate Critical CSS and Load CSS Asynchronously. These can help a lot, and they can also cause a flash of unstyled content or break layouts. Enable one option at a time, purge the cache, and check your homepage, a product page and a form page before moving on.

Never disable security features to chase a score.

Step 7: Re-measure properly

One test run means nothing. After each change:

1. Purge your cache (LiteSpeed Cache → Toolbox → Purge All, or the equivalent in your plugin).
2. Load the page once yourself so the cache is warm.
3. Run PageSpeed Insights three times and take the middle result.
4. Test on mobile, not just desktop — mobile is scored separately and is usually the worse number.

Field data in PageSpeed Insights updates over a rolling 28-day window, so a real improvement for your visitors takes weeks to show up there. Lab data responds immediately.

When the problem is TTFB, not the image

If the breakdown shows most of your LCP is time to first byte, no amount of image work will help. The HTML is arriving slowly — check whether full-page caching is actually serving cached pages, whether a plugin is doing heavy work on every request, and how far your server sits from your visitors.

Gocelerus is cPanel hosting for Southeast Asia with servers in Singapore, NVMe storage and LiteSpeed. If you want to compare what you're paying now against something closer to your visitors in Indonesia or Cambodia, plans are at gocelerus.com/pricing, and moving an existing site over is free — the team handles the migration.