Why Your LCP Image Loads Slowly: 7 Critical Fixes

Introduction

When your LCP image loads slowly, the main content of your page can take longer to appear, even when the rest of the website seems fast. Common causes include late image discovery, oversized image files, inappropriate lazy loading, low resource priority, slow server or CDN delivery, and delays before the browser can render the image. Identifying the specific bottleneck helps you choose the right fix instead of applying every image optimization technique indiscriminately. You have compressed the hero image. You converted it to WebP. You even moved it to a CDN.

Yet PageSpeed Insights still reports a poor LCP.

That situation is more common than it first appears.

An LCP image can be perfectly optimized as a file and still arrive too late. The problem may have nothing to do with compression. The browser might not discover the image early enough, it might select a much larger image than necessary, a lazy-loading rule might delay it, or another resource might be competing for the connection.

There is another possibility that is easy to miss: the image may download quickly but still be painted late.

So when someone says, “My LCP image loads slowly,” there are really several different problems hiding behind that description.

This guide breaks them apart.

Quick Answer

Your LCP image can load slowly because:

• The browser discovers it too late.
• The image file is unnecessarily large.
• The browser downloads a larger responsive variant than needed.
• The image is incorrectly lazy-loaded.
• The image is loaded through JavaScript.
• The image is hidden inside a CSS background.
• The server or CDN responds slowly.
• The image has to travel a long network distance.
• The browser gives more priority to other resources.
• CSS or JavaScript delays the image’s final rendering.
• The page contains too many competing requests.
• The LCP image is being fetched more than once or through an inefficient delivery chain.

The first step is not to compress the image again.

First determine when the browser discovers the image, when it starts downloading it, how long the download takes, and when it is finally rendered.

That tells you what actually needs fixing.

What Makes an Image the LCP Element?

Largest Contentful Paint measures when the largest content element visible in the initial viewport is rendered.

On many pages, that element is an image.

It might be:

• A hero image
• A featured image
• A large product image
• A banner image
• A promotional image
• A background image
• An image inside a prominent content section

But an important distinction is often overlooked:

The LCP image is not necessarily the largest image file on the page.

It is the element that becomes the largest qualifying content element in the viewport during loading.

That means a small, well-optimized image can be your LCP element while a much larger image lower down the page has no direct effect on the LCP timestamp.

This is why optimization should begin with the actual LCP element rather than every image on the page.

The Most Important Question: Where Is the Time Going?

Imagine a page where LCP occurs at 4 seconds.

That does not necessarily mean the image took four seconds to download.

The browser may have spent time doing something else first.

A simplified sequence might look like this:

HTML arrives → image discovered → image request starts → image downloads → image renders → LCP

There can be significant delays between each stage.

For an image LCP, useful diagnostic timing components include:

• Time to First Byte
• Resource Load Delay
• Resource Load Duration
• Element Render Delay

These help answer a much more useful question than simply asking whether the image is “large.”

For example:

Case A

The image is discovered at 0.5 seconds and finishes downloading at 1.5 seconds, but LCP occurs at 2.8 seconds.

The download itself may not be the main problem.

Case B

The HTML arrives at 0.6 seconds, but the image request does not begin until 2.1 seconds.

That points toward a resource discovery problem.

Case C

The image starts downloading at 0.7 seconds but does not finish until 3.5 seconds.

Now image size, network conditions, server delivery, or bandwidth competition deserve closer attention.

The correct fix depends on which pattern you have.

1. The Browser Discovers the Image Too Late

One of the biggest causes of slow LCP images is late resource discovery.

Consider a normal image in HTML:

<img src=”hero.webp” alt=”Example hero image”>

The browser can encounter the image while parsing the document and begin fetching it.

Now compare that with a page where the image only becomes available after JavaScript runs.

The browser has to:

1. Download the HTML.
2. Parse enough of the page to run the required JavaScript.
3. Execute the JavaScript.
4. Generate or modify the image element.
5. Discover the image URL.
6. Request the image.

The image may be perfectly compressed.

It is simply starting too late.

Why late discovery matters

Suppose the image takes 1.2 seconds to download.

If the browser starts downloading it at 0.7 seconds, it could potentially finish around 1.9 seconds.

If JavaScript delays discovery until 2.3 seconds, the same image might not finish until 3.5 seconds.

Nothing changed about the image.

Only the start time changed.

What can cause late discovery?

Common examples include:

• JavaScript-generated image elements
• Client-side rendering
• CSS background images
• Sliders
• Image carousels
• Page-builder components
• Lazy-loading scripts
• Complex component initialization
• Images inserted after API responses
• Incorrect resource-loading logic

For an LCP image, early discoverability is extremely important.

2. Your LCP Image Is Too Large

This is the problem most website owners think about first, and it absolutely can matter.

A modern camera can produce an image thousands of pixels wide.

There is no reason to send that original file to a phone displaying the image at a fraction of that size.

Consider an example:

Original image: 5000 × 3333 pixels
Displayed image: 1200 × 800 pixels

Sending the original may waste bandwidth and increase decoding and transfer work.

The better solution is to generate appropriately sized variants.

File dimensions matter

Do not confuse:

Image dimensions

with

File size

They are related, but not identical.

A 2400 × 1600 image can sometimes be smaller than another image with lower dimensions but inefficient encoding.

Look at both.

Ask:

• Is the image larger than its rendered dimensions?
• Is the compression appropriate?
• Is the format suitable?
• Is the browser receiving the correct variant?
• Is unnecessary image metadata included?
• Is the CDN resizing it efficiently?

Image optimization is about reducing unnecessary work, not simply reaching an arbitrary file-size target.

3. The Browser Downloads the Wrong Responsive Image

Responsive images are particularly important for LCP.

Suppose your page displays the hero image at around 800 pixels wide on a mobile device.

But the browser receives a 2400-pixel-wide version.

The image may still look perfectly sharp.

The problem is that the visitor downloaded substantially more data than was necessary.

Using srcset and sizes gives the browser information about available image sources and their expected display size.

For example:

<img

  src=”hero-1200.webp”

  srcset=”

    hero-480.webp 480w,

    hero-800.webp 800w,

    hero-1200.webp 1200w,

    hero-1600.webp 1600w”

  sizes=”100vw”

  alt=”Example hero image”>

The exact breakpoints should match your actual design.

Do not copy these numbers blindly.

Why sizes matters

srcset tells the browser what image candidates exist.

sizes helps the browser estimate how wide the image will actually be displayed.

If sizes is inaccurate, the browser can choose an image that is larger than necessary.

This is particularly relevant for responsive layouts where the image occupies different widths at different breakpoints.

4. Your LCP Image Is Being Lazy-Loaded

Lazy loading is useful.

It prevents images that are far below the initial viewport from competing with critical resources during page load.

But the image responsible for LCP is already important to the initial viewport.

If you tell the browser to lazy-load it, you may be asking it to postpone a resource that needs to arrive early.

For example:

<img

  src=”hero.webp”

  loading=”lazy”

  alt=”Example hero image”>

If that image is the LCP element, remove the unnecessary lazy-loading behavior.

The exact implementation depends on the website and CMS, but the principle is simple:

Do not treat your critical above-the-fold LCP image like a below-the-fold image.

What about WordPress?

WordPress and performance plugins may automatically add lazy-loading behavior.

That can be useful for most images while still requiring an exception for an important above-the-fold image.

Check what the final HTML actually contains.

Do not assume the settings in your CMS dashboard tell the whole story.

5. The Image Is Loaded Through JavaScript

Some websites do not place the final image URL directly in the HTML.

Instead, JavaScript controls the image.

That can be useful for complex interfaces, but it introduces another dependency before the browser can begin fetching the image.

For a critical LCP image, unnecessary JavaScript involvement can create a resource discovery delay.

If the image is known before the page is sent to the browser, a directly discoverable <img> element can often provide a simpler loading path.

This does not mean JavaScript-driven images are automatically bad.

The question is whether JavaScript is unnecessarily standing between the browser and the resource that determines LCP.

6. Your LCP Image Is a CSS Background

This is another common source of confusion.

A hero image may be implemented like this:

.hero {

  background-image: url(“hero.webp”);

}

Instead of:

<img src=”hero.webp” alt=”Example hero image”>

CSS background images can be useful for decorative layouts, but critical images can become harder for the browser to discover early because the browser must process the stylesheet before it can know about the background resource.

That does not mean every hero background should immediately be converted into an <img>.

If the image is meaningful content, an <img> may be a better semantic and loading choice.

If it is purely decorative, a background image may still be appropriate.

The performance decision should follow the role of the image rather than treating one implementation as universally correct.

7. Your Server Responds Slowly

Sometimes the image itself is not the main problem.

The server delivering the page or image may simply be slow.

A slow initial HTML response can delay everything that follows.

For example:

HTML request starts → server takes 1.5 seconds → browser receives HTML → browser discovers hero image → image request starts

The image cannot be discovered before the browser receives enough HTML to know that it exists.

This is why LCP optimization cannot be reduced to image compression.

Check TTFB

Time to First Byte can help reveal whether the server response is contributing to the delay.

Potential causes include:

• Slow hosting
• Poor page caching
• Backend processing
• Database queries
• Dynamic content generation
• Server resource constraints
• Geographic distance
• CDN configuration

If TTFB is consistently high, optimizing the image may produce only a modest improvement.

8. Your Image CDN Is Not Actually Helping

A CDN can improve delivery by serving static resources from locations closer to users.

But using a CDN does not automatically make every image fast.

Check:

• Where the image is actually being served from
• Whether the image is cached
• Whether the CDN is resizing images
• Whether cache misses are common
• Whether redirects occur before the image request
• Whether image transformations happen on demand
• Whether the origin server remains the bottleneck

A CDN that repeatedly has to retrieve or transform the image from the origin can behave very differently from a properly cached image.

CDN transformation can also matter

Some image CDNs dynamically resize or convert images.

That can be useful, but if the transformation itself adds significant delay or causes repeated cache misses, investigate the complete request chain rather than assuming “CDN” means “fast.”

9. The Image Is Competing With Too Many Other Resources

The browser has limited bandwidth and processing capacity.

A page that immediately requests:

• Several large images
• CSS files
• JavaScript bundles
• Web fonts
• Video
• Analytics
• Advertising scripts
• Third-party resources

can create competition for network and CPU resources.

Your LCP image might be correctly configured but still have to compete with resources that are not essential to the initial view.

This is especially relevant on mobile connections.

Ask what actually needs to load first

For the initial viewport, prioritize resources that contribute directly to the visible experience.

That might include:

• HTML
• Critical CSS
• LCP image
• Required fonts
• Essential JavaScript

Other resources may be able to wait.

This is one reason resource prioritization is more useful than simply trying to make every request load faster.

10. The Browser Gives the LCP Image Too Little Priority

Modern browsers make their own decisions about which resources deserve attention.

You can sometimes provide additional information when a resource is genuinely important.

For an LCP image, fetchpriority=”high” may be appropriate in situations where the browser would otherwise not prioritize the resource sufficiently.

For example:

<img

  src=”hero.webp”

  fetchpriority=”high”

  alt=”Example hero image”>

But this should not be added to every image.

If you mark numerous resources as high priority, you reduce the usefulness of prioritization.

Think of priority as a way to communicate which resource matters most—not as a magic performance switch.

11. The LCP Image Needs Preloading

Preloading can help in certain situations where a critical image is difficult for the browser to discover early.

For example, if a genuinely critical image is referenced indirectly and its discovery is delayed, an appropriate preload can allow the browser to begin fetching it earlier.

However, preload is easy to misuse.

Adding:

<link rel=”preload” as=”image” href=”hero.webp”>

does not automatically make LCP better.

If the browser already discovers the image quickly through the HTML, the preload may provide little benefit.

Worse, excessive preloading can cause unnecessary competition for bandwidth.

Before preloading, ask:

• Is this image actually the LCP resource?
• Is it discovered late?
• Is there a measurable delay before the request starts?
• Is the preload URL exactly the resource that will ultimately be used?
• Is another resource more important?

Preload should solve a demonstrated discovery problem, not be added because a performance article recommended it.

12. The Image File Is Efficient, but the Connection Is Slow

Even a tiny image can take time to arrive over a poor network.

Suppose your hero image is only 100 KB.

That sounds small.

But real visitors may have:

• Slow mobile connections
• High latency
• Congested networks
• Weak cellular signals
• Long network paths

Field data can therefore look considerably worse than a local test.

This is one reason real-user data matters when evaluating Core Web Vitals.

A desktop computer connected to fast broadband is not a representative test environment for every visitor.

13. The Image Has Too Many Redirects

An image request should ideally go directly to the final resource.

If the request passes through several redirects, the browser has additional work to complete before receiving the actual file.

Potential sources include:

• HTTP to HTTPS redirects
• Old image URLs
• CDN redirects
• Domain changes
• Image optimization services
• Tracking layers

Check the network waterfall.

If the image request shows unnecessary redirects, remove them where possible.

14. The Image Is Rendered Late Even After It Downloads

This is an important distinction.

You may look at the network waterfall and think:

“The image finished downloading quickly, so why is LCP still poor?”

Because downloading and rendering are not the same thing.

After the image is available, the browser may still need to perform work involving:

• CSS
• Layout
• JavaScript
• Main-thread tasks
• Rendering
• Compositing

If the image is available but cannot be painted promptly, the problem is no longer simply image transfer.

Example

Imagine:

HTML: 0.5s
Image request starts: 0.7s
Image download finishes: 1.5s
LCP: 2.7s

There is a substantial gap between the image finishing and LCP.

That gap deserves investigation.

Compressing the image further may accomplish almost nothing.

15. Your Image Is Being Replaced After Initial Load

Some pages initially display one image and then replace it with another.

This can happen with:

• Sliders
• Responsive components
• JavaScript galleries
• Personalization
• Lazy-loading libraries
• Client-side image optimization
• Theme scripts

If the browser first loads one resource and then the visible LCP element changes, you may end up with a confusing performance trace.

Inspect the final DOM and network activity rather than assuming the first image request is the one responsible for LCP.

16. Image Format Is Not the Whole Story

WebP and AVIF are useful image formats, but changing formats alone does not guarantee a better LCP.

Consider two scenarios.

Scenario A

A 1.2 MB JPEG is replaced with a 180 KB WebP.

That could produce a substantial improvement.

Scenario B

A 120 KB WebP is converted to a 90 KB AVIF, but the image is still discovered two seconds too late.

The format change may have very little effect on LCP.

The lesson is simple:

Transfer size matters, but timing matters too.

An extremely efficient image that starts downloading late can still be an LCP problem.

How to Diagnose a Slow LCP Image

When PageSpeed Insights reports a poor LCP and the LCP element is an image, follow this sequence.

Step 1: Identify the exact LCP element

Confirm:

• Image URL
• Image dimensions
• Image type
• Location in the page
• Whether it is an <img> or background

Do not optimize a different image by mistake.

Step 2: Check TTFB

Ask:

Did the browser receive the document quickly?

If not, investigate server-side performance.

Step 3: Check image discovery

Ask:

When did the browser first know about the LCP image?

If discovery happens late, investigate:

• JavaScript
• CSS backgrounds
• Lazy loading
• Client-side rendering
• Page-builder behavior

Step 4: Check request start time

Compare the HTML arrival with the image request.

A large gap suggests discovery or prioritization problems.

Step 5: Check transfer duration

If the image starts quickly but takes a long time to finish, investigate:

• Image size
• Network
• CDN
• Server
• Compression
• Responsive image selection

Step 6: Check render delay

If the image finishes downloading but LCP happens much later, investigate:

• CSS
• JavaScript
• Main-thread work
• Layout
• Rendering

This six-step process is much more useful than simply looking at the final image file size.

How to Check This in Chrome DevTools

Chrome DevTools can help you see the image’s loading sequence.

Open the page and launch DevTools.

Go to:

Network → Img

Reload the page.

Find the image that corresponds to the LCP element.

Look at:

• Request start
• Duration
• Size
• Status
• Initiator
• Priority
• Timing information

Then open the Performance panel and record a page load.

Look for the LCP marker and compare it with the image’s network activity.

You are trying to answer three questions:

When was the image discovered?

When did the download begin?

When was the image actually rendered?

Those three moments can tell you much more than the image’s file size alone.

A Simple Example

Imagine a page has a hero image that is 250 KB.

The owner sees the poor LCP and compresses it to 120 KB.

After testing:

Before: LCP 4.1s
After: LCP 3.9s

The improvement is tiny.

Why?

Suppose the trace shows:

HTML arrives: 0.9s
Hero image discovered: 2.4s
Image download: 2.4–3.6s
LCP: 3.9s

The major problem is not the image’s compression.

The browser waited roughly 1.5 seconds before discovering it.

Now imagine the image is made directly discoverable:

HTML arrives: 0.9s
Hero image discovered: 1.0s
Image download: 1.0–2.2s
LCP: 2.4s

The same image can produce a much larger improvement simply because the browser starts fetching it earlier.

That is the kind of diagnosis you want.

How to Fix a Slow LCP Image

Once you identify the bottleneck, choose the appropriate fix.

If discovery is late

Consider:

• Using a directly discoverable <img>
• Removing unnecessary JavaScript dependencies
• Avoiding unnecessary lazy loading
• Reviewing CSS background usage
• Correctly prioritizing the resource
• Using preload only when justified

If the image is too large

Consider:

• Resizing it
• Compressing it
• Using a more efficient format
• Removing unnecessary metadata
• Generating responsive variants

If the wrong responsive size is selected

Review:

• srcset
• sizes
• CSS layout width
• Breakpoints
• Device-specific image variants

If the server is slow

Investigate:

• Page caching
• Hosting
• Backend processing
• Database queries
• CDN configuration
• Origin response time

If delivery is slow

Investigate:

• CDN caching
• Network distance
• Image transformations
• Cache misses
• Redirects
• Origin performance

If rendering is late

Investigate:

• CSS
• JavaScript
• Main-thread tasks
• Layout work
• Third-party scripts

Should You Always Use fetchpriority=”high”?

No.

It can be useful for a genuinely important image, especially when the browser’s default prioritization does not get the resource started early enough.

But adding it everywhere is not a performance strategy.

A page with ten “high-priority” images has not suddenly become ten times faster.

Priority hints are most useful when applied selectively.

For an LCP image, verify that the resource really is critical before assigning elevated priority.

Should You Always Preload the LCP Image?

No.

Preloading is useful when it addresses a real resource-discovery problem.

It is less useful when the image is already easily discoverable in the HTML.

It can also create competition with other critical resources if used indiscriminately.

If you preload an image, make sure the preload corresponds to the image that the browser will actually use.

For responsive images, preload configuration also needs to account for the resource variant the browser should select.

Should You Convert Every LCP Image to WebP or AVIF?

Not necessarily.

Efficient formats can reduce transfer size, but format selection is only one part of LCP optimization.

Consider:

• Image dimensions
• Compression
• Browser support requirements
• Responsive variants
• Delivery location
• Discovery timing
• Priority
• Rendering

A smaller file that starts two seconds late is still late.

What About Hero Images in CSS?

If a hero image is meaningful content, an actual image element can provide advantages in semantics, accessibility, and resource discovery.

If the image is decorative, CSS may still be the right implementation.

Do not rewrite an entire design simply because a background image exists.

Instead, determine whether the implementation is creating measurable LCP delay.

Performance optimization should solve a real bottleneck rather than turn every implementation choice into a rule.

WordPress: Why LCP Images Often Become Complicated

WordPress can introduce several layers between the original image and the browser:

Media Library → Theme → Page Builder → Optimization Plugin → Lazy Loader → CDN → Browser

Any one of those layers can affect how the LCP image is delivered.

Check the final page source and network requests rather than relying solely on WordPress settings.

Look for:

• loading=”lazy”
• fetchpriority
• srcset
• sizes
• CDN URLs
• Image transformation URLs
• JavaScript-generated images
• CSS background images
• Duplicate image requests

A WordPress dashboard may say that an image is optimized, while the browser may still be receiving a larger variant or discovering it later than necessary.

The browser’s actual behavior is what matters.

Common Mistakes When Optimizing an LCP Image

Mistake 1: Compressing the image repeatedly

If the image is already small enough, additional compression may produce little improvement.

Find the actual bottleneck first.

Mistake 2: Lazy-loading the hero image

Lazy loading is intended to defer resources that are not immediately needed.

Your LCP image is normally needed immediately.

Mistake 3: Preloading everything

Preload is not a universal speed button.

Too many preloads can compete for bandwidth.

Mistake 4: Making every image high priority

Priority only works as a useful signal when there is meaningful prioritization.

Mistake 5: Ignoring sizes

A responsive image can still be oversized if the browser is given poor information about its expected display width.

Mistake 6: Looking only at file size

A 100 KB image can still have poor LCP if it is discovered late.

Mistake 7: Testing only on desktop

Real users may have slower devices and networks.

Always consider mobile and field data.

Mistake 8: Changing everything at once

If you change the image format, CDN, theme, caching, JavaScript, CSS, and preload settings simultaneously, you lose the ability to identify which change actually helped.

LCP Image Optimization Checklist

Identify

• Find the actual LCP element
• Confirm its image URL
• Check whether it is an <img> or CSS background
• Check its displayed dimensions

Discovery

• Confirm when the browser discovers the image
• Check whether JavaScript is involved
• Check whether lazy loading is applied
• Check whether CSS delays discovery
• Look for unnecessary redirects

Image

• Use an appropriate image format
• Compress the image
• Resize oversized images
• Generate responsive variants
• Check srcset
• Check sizes

Delivery

• Check TTFB
• Check CDN behavior
• Check cache status
• Check network distance
• Check image transformation time

Priority

• Decide whether the image needs elevated priority
• Use fetchpriority=”high” only when appropriate
• Consider preload only when discovery is genuinely delayed
• Avoid prioritizing non-critical images

Rendering

• Check CSS
• Check JavaScript
• Check main-thread work
• Check render delay
• Check for image replacement

Verification

• Retest on mobile
• Run multiple tests
• Compare before and after
• Check field data
• Monitor for regressions

A Better Way to Think About LCP Images

It is tempting to reduce the problem to:

“Make the image smaller.”

A better model is:

Discover it early → request the right resource → deliver it efficiently → render it promptly.

Every stage matters.

A 2 MB image that starts immediately might outperform a 100 KB image that the browser does not discover until several seconds into the page load.

Likewise, a perfectly optimized image can still produce poor LCP if the server is slow or the browser spends too much time processing other work before rendering it.That is why LCP image optimization is fundamentally about loading strategy, not just image compression.

Final Verdict

A slow LCP image is not always a slow image file.

That distinction can save a lot of wasted optimization work.

If your hero image is 2 MB, obviously reducing its size matters. But if the image is already reasonably small and the browser does not request it until several seconds after the HTML arrives, compressing it again is unlikely to solve the real problem.

Start with the loading sequence.

Find the LCP element.

Then ask:

When was it discovered?

When did the request start?

How long did the download take?

When was it finally rendered?

Those answers point toward the right fix.

For late discovery, improve how the browser finds the resource. For excessive transfer size, optimize the image and responsive variants. For slow delivery, investigate the server, CDN, network, and caching. For render delay, look beyond the image itself at CSS, JavaScript, and main-thread work.

The best LCP image is not simply the smallest image.

It is the right image, discovered early, delivered efficiently, and rendered when the user needs.

Related Articles:

• What Is LCP? 7 Powerful Ways to Improve Loading Speed
• Image Optimization: 9 Powerful Ways to Speed Up Your Website
• How TTFB Affects LCP: 7 Critical Fixes for Faster Loading
• Above-the-Fold Optimization: 7 Powerful Speed Fixes
• How a CDN Improves Website Speed: 7 Powerful Benefits
• Website Speed Audit: 9 Powerful Steps to Fix Slow Pages

Recommended Resources:

• web.dev: Optimize Largest Contentful Paint: Learn how resource discovery, loading priority, and rendering affect LCP. https://web.dev/articles/optimize-lcp
• web.dev: Optimize Images: Explore image formats, compression, and efficient image delivery. https://web.dev/learn/images
• MDN: Fetch Priority: Understand how the fetchpriority attribute helps communicate resource importance to the browser. https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/fetchpriority
• MDN: Responsive Images: Learn how srcset and sizes help browsers select appropriate image sizes. https://developer.mozilla.org/en-US/docs/Web/HTML/Guides/Responsive_images
• Google PageSpeed Insights: Test your page and review available LCP diagnostics. https://pagespeed.web.dev/