Google's Core Web Vitals made page load performance a direct ranking factor, and among the three metrics, Largest Contentful Paint (LCP) is usually the hardest one to pass. Unoptimized, heavy hero images are the most common reason behind a poor LCP score, and the frustrating part is that most fixes for this are small, specific, and easy to get slightly wrong.
Welcome back to BytebaseX. I'm Suptojit Modak, and in this ninth guide of the Image Optimization series, I'll break down exactly how heavy images slow down LCP, walk through the four phases Google actually measures, and give you the specific technical fixes that move the needle. If you missed the previous guide on responsive images with srcset and <picture>, you can read it here.
What LCP Actually Measures
Largest Contentful Paint measures how long it takes for the largest visible element above the fold, usually a hero image, a featured photo, or a large text block, to fully render in the visitor's viewport. To pass Google's threshold, this element needs to render in 2.5 seconds or less, measured at the 75th percentile of real visits, meaning three out of four of your visitors need to see it that fast, not just your fastest ones.
Here's something worth knowing before diving into the fixes: LCP is a field metric, based on real Chrome users over the past 28 days, and it's what Google actually uses for ranking. The number you see in Lighthouse or PageSpeed Insights is a lab metric, a single synthetic test run on one machine. The two numbers routinely disagree, usually because real visitors are on slower phones and shakier connections than the test environment. Don't panic if your lab score looks worse than your real-world Search Console data, or the other way around; they're measuring different things.
The Four Real Phases of LCP
When your LCP element is an image, its total load time breaks down into four distinct phases, not three. This matters because each phase has a different cause and a different fix, so knowing which one is actually slow tells you exactly where to spend your effort instead of guessing.
- Time to First Byte (TTFB): the time from when the visitor requests your page to when their browser receives the very first byte of the HTML response. This covers DNS lookup, server connection, and how long your backend takes to respond. A good target is under 800 milliseconds. If your TTFB is slow, no amount of image optimization fixes it, since the browser can't even start looking for the image until the HTML arrives.
- Resource Load Delay: the gap between receiving the HTML and the browser actually starting to download the LCP image. This is the phase where most image-driven LCP problems live, and it's the one this post focuses on fixing.
- Resource Load Duration: how long it actually takes to download the image once the request starts. This is driven mostly by file size, which is why compression and format choice matter here.
- Element Render Delay: the time between the image finishing its download and actually appearing on screen. This can be delayed by render-blocking CSS or JavaScript that the browser has to process first.
Google's own guidance suggests the two delay phases, resource load delay and element render delay, should together account for no more than about 20% of your total LCP time. Ideally, most of your LCP budget should go toward actually loading the resource, not sitting around waiting to start or waiting to render. If your delay phases are eating a big chunk of your LCP time, that's a strong signal something in your setup, not your image size, is the real bottleneck.
How to Actually Check Which Phase Is Slow
Guessing which phase is the problem wastes time, and the good news is you don't have to. Open Chrome DevTools, go to the Performance panel, and record a page load. In the resulting trace, look for the LCP marker, and Chrome will show you the phase breakdown directly, how much time went to TTFB, load delay, load duration, and render delay, as a percentage of the total.
PageSpeed Insights does this too, in a simpler form. Run your URL through it, and under the LCP entry in the diagnostics section, you'll see the same four-way split. If resource load delay is eating 40% of your LCP time, that's your priority, not compression. If resource load duration is the bulk of it, your image file size is genuinely the bottleneck, and compression or format conversion is where to spend your time. Fixing the wrong phase, like heavily compressing an already-small image when your real problem is a late-discovered background image, burns effort without moving your score.
Fixing Resource Load Delay: Getting the Browser to Start Sooner
This phase is where the most common, and most avoidable, mistakes happen.
1. Never Lazy Load Your LCP Image
A frequent mistake, covered in an earlier post in this series, is applying loading="lazy" across every image on a site without exception. Lazy loading tells the browser to wait before even starting to fetch an image, which is exactly backwards for the one image the visitor sees the instant the page loads. For your main hero or featured graphic, skip lazy loading entirely and add high fetch priority instead:
<!-- Correct implementation for the primary above-the-fold hero image -->
<img src="hero-banner.avif"
alt="Main product showcase"
width="1200"
height="630"
fetchpriority="high">2. Preload the Image If It's Hidden from Early HTML Scanning
Browsers scan your HTML early to discover images they'll need, but that scan can't see everything. If your hero image is set through a CSS background-image property, or only gets rendered after client-side JavaScript runs, the browser has no way to know about it until much later in the page load, which directly adds to resource load delay. A <link rel="preload"> tag in your <head> tells the browser about the image immediately, before it would otherwise be discovered:
<link rel="preload" as="image" href="hero-banner.avif" type="image/avif" fetchpriority="high">Use this specifically for images the browser would otherwise discover late. If your hero image is already a plain <img> tag sitting near the top of your HTML, it's likely being discovered early already, and preloading it on top of that adds limited extra benefit.
Fixing Resource Load Duration: Making the File Smaller
Once the browser starts downloading, the only lever left is file size, and this is where the earlier posts in this series come together. Replacing an oversized PNG or an uncompressed JPEG with AVIF or WebP, using lossy compression around 80% quality, and resizing the image to its actual display dimensions before uploading typically cuts file size by 30% to 70% combined. A smaller file simply finishes downloading sooner, which is a direct, linear improvement to this phase, no guesswork involved.
Fixing Element Render Delay: Removing What's in the Way
Even after the image finishes downloading, the browser might not render it right away if it's stuck waiting on other things, typically render-blocking CSS or JavaScript that has to finish executing first. Keeping your critical CSS small and deferring non-essential JavaScript (using the defer or async attributes on script tags) reduces how long the browser sits idle between "image downloaded" and "image visible."
Don't Forget Layout Stability
Always declare explicit width and height attributes on your LCP image. This doesn't directly speed up LCP, but it lets the browser reserve the correct amount of space on the page before the image loads, which prevents Cumulative Layout Shift (CLS), a separate Core Web Vital that measures how much your page jumps around during load. Fixing LCP while accidentally breaking CLS isn't a net win, so this small addition is worth doing alongside everything else here.
Summary: Where Each Fix Applies
| Optimization | LCP Phase It Targets | Expected Impact |
|---|---|---|
Remove loading="lazy" from hero images |
Resource Load Delay | High, triggers the download immediately instead of waiting |
Add fetchpriority="high" |
Resource Load Delay | High, tells the browser to prioritize this download over less critical ones |
Preload via <link rel="preload"> |
Resource Load Delay | Medium to high, mainly for images hidden from early HTML scanning |
| Convert to AVIF or WebP, compress, resize | Resource Load Duration | High, directly cuts the bytes that need to download |
| Defer non-critical CSS and JavaScript | Element Render Delay | Medium, removes what's blocking the browser from displaying the image |
| Set explicit width and height | Layout stability (CLS, not LCP directly) | Prevents a separate Core Web Vitals problem while you're in here anyway |
Conclusion
Optimizing your LCP element is one of the fastest ways to improve both real user experience and your Core Web Vitals score, but it works best when you know which of the four phases is actually slow before you start changing things. A slow TTFB needs server or hosting work, not image fixes. A slow resource load delay usually means lazy loading was applied somewhere it shouldn't be, or the image is hidden from early discovery. A slow resource load duration means the file itself is still too heavy. Diagnose first, then apply the fix that actually matches the problem, and you'll get your LCP comfortably under that 2.5-second threshold without guessing.
This post is part of the ongoing Image Optimization series on BytebaseX. In the next post, I'll cover Image SEO and social share best practices, including og:image tags, to help your images perform well in both search results and social media previews.
