Do Image CDNs Improve LCP? Test Setup, Results, and Fixes

Short answer: yes, image CDNs can improve LCP.

But only when your LCP problem is the image itself.

If the LCP image is too large, too far from the user, served as JPEG/PNG when WebP or AVIF would be smaller, or missing responsive sizes, an image CDN can move the number meaningfully.

If the LCP image is lazy-loaded, hidden behind JavaScript, used as a CSS background, discovered late, blocked by render-heavy scripts, or delayed by slow HTML TTFB, a CDN alone will not fix it.

That is the honest answer.

TL;DR: An image CDN improves LCP by reducing resource load duration: fewer bytes, better format, closer edge, responsive dimensions. It does not fix resource load delay or render delay unless you also make the LCP image discoverable in HTML, preload it when needed, and set fetchpriority="high".

What Exactly Does LCP Measure?

LCP measures when the largest visible image or text block in the viewport finishes rendering.

Google's good threshold is 2.5 seconds or less for at least 75% of page visits, according to the web.dev LCP optimization guide.

For image-heavy pages, the LCP element is often:

• A hero image
• A product image
• A featured blog image
• A large banner
• A background image
• A large text block using a web font

Image CDNs only help directly when the LCP element is an image.

If your LCP element is text, the fix is probably TTFB, render-blocking CSS, font loading, or client-side rendering.

Where Can an Image CDN Improve LCP?

Google breaks LCP into four useful parts:

This is the key.

Most image CDNs improve resource load duration. They reduce file size, choose WebP/AVIF, resize the image to the display width, cache the derivative, and serve it from an edge location.

That is real.

But if the browser starts downloading the LCP image 1.8 seconds late, making the image smaller only fixes the last part of the problem.

How do you measure LCP improvement properly?

Do not test with a random homepage once and call it done.

Use the same page, same image, same viewport, same throttle, and same LCP element across all variants.

Here is the clean setup:

Keep the rest of the page unchanged.

Test mobile first. LCP problems usually show up harder on mobile because CPU, bandwidth, and viewport constraints are tighter.

Use:

• Chrome DevTools Performance panel
• PageSpeed Insights lab diagnostics
• WebPageTest waterfall if you want filmstrips
• CrUX or RUM data for real users after deployment

One Lighthouse run is not enough. Run at least 3-5 tests per variant and compare medians.

What usually changes in LCP results after adding an image CDN?

Here is the result pattern I see when the LCP element is a large image.

The important result is not "CDN equals faster."

The important result is this:

Image CDNs improve LCP only when they reduce the time between the browser requesting the LCP image and the browser receiving enough bytes to render it.

If the image request starts late, fix discovery.

If the image request is huge, fix bytes.

If the image is loaded but does not render, fix render blocking.

Why a CDN Alone Sometimes Does Nothing

This is where many performance fixes fail.

You install an image CDN. Lighthouse still complains. Then the CDN gets blamed.

But the problem was never the CDN.

Common reasons:

• The LCP image is a CSS background and discovered after CSS loads.
• The LCP image has loading="lazy".
• JavaScript swaps the image after hydration.
• The image is below an animation or skeleton loader.
• The browser downloads five other high-priority resources first.
• The HTML TTFB is already too slow.
• The image is on a third-party CDN domain without preconnect.

Google's Optimize LCP guide specifically calls out that late discovery and render delay can dominate LCP. An image CDN cannot solve those by itself.

Why must the LCP image be discoverable early?

The browser should see the LCP image in the initial HTML whenever possible.

Good:

<img
  src="https://cdn.example.com/hero.jpg?width=800&quality=80&format=auto"
  width="800"
  height="450"
  alt="Product dashboard"
  fetchpriority="high"
>

Risky:

<div class="hero"></div>

.hero {
  background-image: url("/hero-large.jpg");
}

The background image version can work, but the browser discovers it later because it has to download and parse CSS first.

For LCP, simple HTML usually wins.

Should You Preload the LCP Image?

Sometimes, yes.

Preload helps when the LCP image is not discovered early enough. Google's responsive image preload guide explains how imagesrcset, imagesizes, and fetchpriority help the browser choose and fetch the right resource earlier.

For a simple img tag already in the first HTML, fetchpriority="high" may be enough.

For a hero image hidden behind CSS or JavaScript, preload can matter more.

Example:

<link
  rel="preload"
  as="image"
  href="https://cdn.example.com/hero.jpg?width=800&quality=80&format=auto"
  fetchpriority="high"
>

For responsive images:

<link
  rel="preload"
  as="image"
  imagesrcset="
    https://cdn.example.com/hero.jpg?width=480 480w,
    https://cdn.example.com/hero.jpg?width=800 800w,
    https://cdn.example.com/hero.jpg?width=1200 1200w
  "
  imagesizes="100vw"
  fetchpriority="high"
>

Do not preload every image.

Only preload the likely LCP image.

What Chrome's Image Delivery Insight Checks

Chrome's image delivery insight focuses on the practical part: reduce image download time.

It checks whether images are unnecessarily large, whether modern formats could save bytes, and whether responsive sizing would reduce transfer size. Chrome's docs say deploying an image CDN can help with all of those strategies.

That matches the real-world pattern.

An image CDN helps most when it handles these jobs automatically:

• Compress original images
• Convert JPEG/PNG to WebP or AVIF
• Resize based on viewport
• Cache derivatives at the edge
• Avoid serving 2,400 px images to 390 px screens

If your current image is already correctly sized, already WebP/AVIF, and already cached close to users, the CDN win may be small.

Which image CDN is best for LCP: BunnyCDN, ImageKit, or Cloudflare?

All three can improve LCP. They just do it differently.

For WordPress, BunnyCDN is the simplest paid value if you want predictable cost. ImageKit is excellent if you want more transformation control. Cloudflare Images is clean if your whole stack already lives behind Cloudflare.

For deeper provider math, use the paid image CDN options guide and free image CDN comparison.

How do you set up WordPress for a better LCP score?

For WordPress, the LCP image is usually the featured image or first hero image.

Do this:

1. Use an image CDN or optimizer that generates WebP.
2. Make sure WordPress outputs srcset.
3. Do not lazy-load the first hero or featured image.
4. Add fetchpriority="high" to the LCP image.
5. Set explicit width and height.
6. Avoid sliders above the fold.
7. Use a CDN hostname that can be preconnected or same-origin proxied.

Bad WordPress pattern:

<img
  src="/wp-content/uploads/hero-2400.jpg"
  loading="lazy"
  width="2400"
  height="1350"
>

Better:

<img
  src="https://cdn.example.com/wp-content/uploads/hero.jpg?width=800&quality=80"
  srcset="
    https://cdn.example.com/wp-content/uploads/hero.jpg?width=480 480w,
    https://cdn.example.com/wp-content/uploads/hero.jpg?width=800 800w,
    https://cdn.example.com/wp-content/uploads/hero.jpg?width=1200 1200w
  "
  sizes="100vw"
  width="800"
  height="450"
  fetchpriority="high"
  decoding="async"
  alt="Homepage hero"
>

The CDN is only one part. The markup matters.

How do you configure Next.js to optimize LCP?

For Next.js, the common mistake is assuming next/image automatically solves everything.

It helps, but only if configured correctly.

Use priority or preload behavior for the above-the-fold LCP image, configure the loader, and make sure the CDN URL receives the right width and quality.

Example custom loader idea:

type LoaderProps = {
  src: string
  width: number
  quality?: number
}

export function imageCdnLoader({ src, width, quality = 80 }: LoaderProps) {
  return `https://cdn.example.com${src}?width=${width}&quality=${quality}&format=auto`
}

Then:

<Image
  loader={imageCdnLoader}
  src="/hero.jpg"
  alt="Product dashboard"
  width={1200}
  height={675}
  priority
/>

For more detail, see the Image CDN for Next.js guide.

What is the ultimate LCP testing checklist?

Use this checklist before and after adding an image CDN.

• Identify the real LCP element in PageSpeed Insights or DevTools.
• Confirm whether it is image or text.
• Measure TTFB.
• Check when the LCP image request starts.
• Check image transfer size.
• Check rendered dimensions vs intrinsic dimensions.
• Check format: JPEG, PNG, WebP, or AVIF.
• Check whether the image has loading="lazy".
• Check whether fetchpriority="high" is present.
• Check whether the image is in HTML or CSS.
• Check cache headers.
• Test mobile, not only desktop.

The fastest image CDN in the world will not help if the browser starts the image request too late.

When an Image CDN Is Worth It for LCP

Use an image CDN when:

• The LCP image is larger than it needs to be.
• You serve JPEG/PNG when WebP or AVIF would be smaller.
• You need responsive image sizes but do not want to generate them manually.
• Your users are far from your origin server.
• Your CMS creates inconsistent image sizes.
• Your team keeps uploading giant images.

Do not expect an image CDN to fix:

• Slow HTML TTFB
• Render-blocking CSS
• Heavy hydration
• Late JavaScript image injection
• Lazy-loaded hero images
• Layout shifts from missing dimensions
• Wrong LCP element selection

This is the line I would keep in mind:

Image CDN first fixes bytes. Markup fixes discovery. Frontend performance fixes render delay.

You need all three for a consistently good LCP.

What is the final verdict?

Image CDNs do improve LCP, but not by magic.

They help when the LCP problem is image weight, format, sizing, distance, or caching. They do not help much when the real problem is late discovery, lazy loading, slow HTML, render-blocking CSS, or JavaScript hydration.

My practical recommendation: add an image CDN, but test the LCP subparts before calling the job finished. For most sites, the winning setup is simple: responsive CDN image, WebP/AVIF, no lazy loading on the hero, fetchpriority="high", correct dimensions, and a clean cache policy.