An image CDN is a content delivery network that resizes, compresses and converts images on request, then caches each version near shoppers. On eCommerce sites it cuts image weight across the catalog. It won’t fix the wait before the browser requests your hero image, which is usually the bigger delay.
What is an image CDN?
An image CDN is a service that transforms, optimizes and delivers images. You upload one high-resolution master. The image URL carries parameters for size, format and quality, so one file can produce every variant a page needs. The first request for a variant generates it, and the CDN caches the result for everyone after that, according to Google’s web.dev guide to image CDNs.
Most image CDNs also choose the format for you. The browser’s Accept header tells the CDN which encodings it supports, so a Chrome shopper can get AVIF while an older browser gets JPEG from the same URL. You stop maintaining separate WebP and AVIF files and stop wrapping every image in a picture element.
What does an image CDN fix on an eCommerce site?
On a large catalog, an image CDN fixes five things:
- File size. Google’s web.dev article on image CDNs (2019) puts typical savings from switching at 40% to 80% of image file size.
- Dimensions. One master produces every width your srcset needs, so phones stop downloading desktop-sized product shots.
- Format. AVIF or WebP goes to browsers that support it, with JPEG as the fallback, through content negotiation.
- Catalog scale. Thousands of SKUs, each in several sizes and formats, without a rendition pipeline in your DAM or PIM.
- Distance. Cached variants are served from the edge instead of your origin.
Fewer bytes help almost everywhere. Google’s own analysis says it plainly: “Sending fewer bytes to your users is almost always a win.”
Why doesn’t an image CDN fix slow LCP on its own?
Largest Contentful Paint (LCP) measures when the main content appears, and Google rates 2.5 seconds or less as “good.” On product and category pages the LCP element is usually an image, so image weight looks like the obvious culprit. Google’s field data says otherwise.
In a web.dev analysis of Chrome field data (Brendan Kenny, last updated August 20, 2024), origins with poor LCP spent their time like this at the 75th percentile:
- Time to first byte: 2,270 ms
- Waiting before the image request starts (resource load delay): 1,290 ms
- Downloading the image (resource load duration): 350 ms
- Render delay after the image arrives: 360 ms
The majority of poor-LCP origins spend less than 10% of their LCP time downloading the LCP image. The median poor-LCP site waits almost four times as long to start the download as it spends on the download itself. An image CDN shrinks the 350 ms. The 1,290 ms waiting time is still there.
For more on why image weight alone rarely explains LCP, see our post on the anatomy of LCP.
How do you get the LCP image requested sooner?
Load delay is the time between the first byte of HTML and the browser asking for the LCP image. Four fixes shorten it:
- Make the image discoverable in the HTML. Use a plain img tag for the hero banner and the main product shot. Background images set in CSS and images injected by JavaScript wait on other files first. In the same web.dev analysis, median LCP rose from 2,150 ms with no dependent requests to 2,540 ms with one and 2,850 ms with two.
- Tell the browser it matters. Add fetchpriority=”high” to the LCP image and never lazy-load it. Preload it when it can’t be an img tag. Few sites do this: only 2.1% of pages preload their largest image (HTTP Archive Web Almanac, January 15, 2026).
- Avoid a new connection. An image CDN on a separate domain adds connection setup. Google recommends proxying images through your main origin where possible, or preconnecting to the image CDN early.
- Keep third-party scripts out of the way. Tag managers, reviews, chat and personalization all request files during load. The browser often doesn’t know which element will be the LCP until many of those resources have loaded, according to web.dev. Third-party apps account for 44% of eCommerce load time, based on Yottaa’s data. Loading non-essential scripts after the main content renders gives the hero image room.
How do you know if your image CDN is working?
Check field data, not a single Lighthouse run. Then read it in this order:
- LCP by template and device. Mobile product and category pages carry the most images and the most third-party code.
- LCP subparts. Google’s web-vitals library (attribution build) reports TTFB, load delay, load duration and render delay. If load duration fell after the switch and LCP didn’t move, the bottleneck is upstream of the image.
- Cache hit ratio for image variants. A miss means the variant is generated on request. Long-tail SKUs and rarely used sizes miss most often.
- Time to first byte. If your TTFB alone is over two seconds, fix HTML delivery before tuning image settings.
The milliseconds are worth chasing. Shopify’s analysis of its own stores (April 27, 2026) found that every 100 milliseconds of load time costs 3.5% of conversion rate.
How Yottaa helps with both halves
Yottaa covers the delivery side and the page side. Through our premium partner program, Yottaa runs managed infrastructure on Fastly, including their Image Optimizer for automatic image optimization and transformation, plus edge caching, configured and operated by Yottaa’s team. On the page, Rapid’s Application Sequencing controls when third-party scripts load, so critical content renders first and non-essential tools wait.
Yottaa RUM then shows whether it worked. It tracks images, fonts, CSS, JavaScript and third-party resources in real shopper sessions, and correlates browser data with cache status, CDN processing time and origin response. You can see whether a slow LCP starts at the edge, the origin or the page.
FAQ
What is the difference between a CDN and an image CDN?
A standard CDN caches and delivers your files as they are. An image CDN also transforms them, resizing, compressing and converting format for each request, then caches every variant at the edge.
Does an image CDN improve Core Web Vitals?
It can improve LCP when image download is a large share of it, and it reduces bytes on every page. For most sites with poor LCP, Google’s field data shows the wait before the image request and the server response take longer than the download. Pair an image CDN with early discovery and prioritization of the LCP image.
Should you lazy load product images on eCommerce sites?
Lazy-load images below the fold, such as lower rows on a category page. Never lazy-load the main product image or the hero banner. Those are usually the LCP element, and lazy loading delays the request.
WebP or AVIF for eCommerce images?
Let the image CDN decide per browser. With content negotiation it serves AVIF where supported and falls back to WebP or JPEG, so you keep one master image and one URL.
Subscribe to our blog
Performant Experimentation – A Guide to A/B Testing
Every A/B test you run is a purchase. You’re buying information—an answer to a hypothesis—and you’re paying for it in degraded performance and lost conversion during the test window.
Download eBook
