What an image CDN actually does
A standard CDN caches your files at edge locations worldwide so a shopper downloads them from a nearby server instead of your origin. An image CDN adds a transformation layer on top: it resizes, compresses, and converts formats per-request based on the visitor's device and browser.
That distinction matters. A plain CDN serving a 2MB hero JPEG to everyone is still serving 2MB. An image CDN serving that same source file delivers a right-sized, modern-format version — often 60–80% smaller — without you ever creating those variants manually.
Store one high-resolution master per product and let the CDN derive every size and format from it. Pre-generating dozens of crops by hand is the workflow an image CDN is designed to eliminate.
Three things happen at the edge with a well-configured image CDN:
- Right-sizing: a 300px thumbnail slot gets a 300px image, not a downscaled 2000px file.
- Format negotiation: the CDN reads the browser's
Acceptheader and serves AVIF, WebP, or JPEG accordingly. - Smart compression: quality is tuned per-image so detail-heavy products stay crisp while flat backgrounds compress hard.
The performance payoff, in numbers
The case for an image CDN isn't abstract. Product images are the primary cause of poor LCP in e-commerce — on 84% of product pages, the main product image is the LCP element. Fix image delivery and you fix the metric Google weights most heavily for retail.
Real brands have published the downstream revenue impact of getting this right:
| Brand | Optimization | Result |
|---|---|---|
| Rakuten | Core Web Vitals improvements | +33% conversions, +53% revenue/visitor |
| Vodafone | 31% LCP improvement | +8% sales |
| Retail (aggregate) | Every 0.1s faster | +8% conversions |
For geographically spread audiences, the edge-delivery benefit compounds: a CDN can pull time to first byte from ~500ms down to under 100ms for 90% of users by serving from the nearest point of presence.
Choosing your formats: AVIF, WebP, and the JPEG fallback
Format selection is where most of the byte savings live. Modern formats deliver the same visual quality at a fraction of the size, and an image CDN lets you adopt them without breaking older browsers.
AVIF runs roughly 65% smaller than JPEG at equivalent quality, and WebP about 50% smaller. AVIF also holds up better than WebP on the fine detail that matters for jewelry, textiles, and luxury goods — important if your products live or die on texture fidelity.
The practical setup is a cascade: serve AVIF to browsers that accept it, WebP to the rest, and JPEG as the universal fallback. A good image CDN handles this negotiation automatically from the Accept header — you upload one master file and the right format goes out per request.
Aggressive AVIF compression can smear subtle gradients and product texture. If your catalog leans on material detail, set a higher quality floor for AVIF and verify a few SKUs visually before rolling it out catalog-wide.
Setting it up on your platform
Implementation depends on your stack, but the pattern is consistent: point image requests at the CDN, let it pull from your origin, and configure transformation defaults.
Shopify: the platform already serves images through its own CDN with URL-based transforms (append ?width= parameters). You get format negotiation for free, but you don't control compression aggressiveness — for fine-grained control, a third-party image CDN that proxies your asset domain gives you more headroom.
WooCommerce / WordPress: a plugin (or a Cloudflare/Cloudinary integration) rewrites image URLs to route through the CDN. Pair it with native srcset output so the browser requests the right size.
Custom / headless storefronts: put Cloudflare Images, Cloudinary, imgix, or CloudFront-with-Lambda in front of your image bucket and rewrite <img> sources to the CDN domain. This is where image CDNs shine — full control over transforms, format, and caching.
Without an image CDN
- One oversized file served to every device
- Manual variant generation per size
- Origin server handles every image request
- JPEG/PNG only — no modern formats
With an image CDN
- Right-sized, per-device delivery
- Variants generated on the fly from one master
- Edge caching offloads your origin
- Automatic AVIF/WebP negotiation
The configuration details that decide your results
Installing a CDN gets you the 30% win. The other 30% comes from configuration. Work through this checklist:
- Set explicit width and height on every
<img>tag. This reserves layout space and prevents Cumulative Layout Shift — a Core Web Vital independent of file size. - Use
srcsetwith multiple widths so each viewport downloads only the resolution it needs. - Do NOT lazy-load the LCP image. The main product image and hero should load eagerly with
fetchpriority="high"; lazy-loading them delays the exact element Google measures. - Lazy-load everything below the fold — gallery thumbnails, related products, footer imagery.
- Tune cache TTLs so transformed variants stay at the edge and don't re-process on every request.
- Set sensible quality defaults — around 75–85 for JPEG/WebP is usually indistinguishable from the original at far smaller sizes.
Quality starts upstream. A CDN can shrink and reformat a clean, well-lit master, but it can't fix a noisy or poorly retouched source — compression actually amplifies artifacts. Retouchable produces clean, high-resolution masters that compress beautifully, so your CDN can push file sizes down without visible quality loss.
Get the source right, hand a single high-quality master to your image CDN, and the rest of the pipeline — sizing, format, delivery — runs itself on every product page you publish.