Image CDN vs Regular CDN
A regular CDN moves your files closer to your visitors without changing them. An image CDN also changes them, generating the size, format, and compression each request asks for. Both cache at the edge; only one has an opinion about what it is serving. The image CDN overview covers what that costs and how to pick one.
What they share
They share the delivery half entirely. Both keep copies at edge locations near visitors, both serve from cache after the first request, both take load off your origin. If you already know what a CDN is, none of that will be new.
What differs is the file itself. A regular CDN is faithful to a fault: upload a 4 MB photograph and every visitor gets 4 MB, quickly and from nearby, but 4 MB. The phone on a train gets exactly what the desktop on fibre gets.
An image CDN treats the stored file as a source rather than something to hand over. From one original it produces a 400 pixel version, an 800 pixel one, a 1600 pixel one, in AVIF or WebP or JPEG, at whatever quality you ask for, each generated on first request and cached after that.
Where a plain CDN runs out
Images are usually the heaviest thing on a page, so once distribution is sorted, image weight tends to be what is left.
Some things a plain CDN cannot help with:
- A photo uploaded straight off a phone, several thousand pixels wide, displayed in a 600 pixel column.
- A library still served as JPEG, because converting to AVIF would mean re-encoding every file and keeping both copies around.
- A page that wants four or five widths of the same image for its responsive markup, none of which exist.
Edge caching does nothing for any of those. In each case the file is simply wrong for the request that arrived.
When you do not need one
If your images are already correct, the transformation layer has nothing left to do.
A site with a dozen hand-picked images, each exported at the display size and already in a modern format, is fine on a plain CDN. So is one where every image is a fixed-size avatar generated at upload. The work has already been done, and doing it again at the edge just adds a moving part.
Where it stops being fine is when other people upload. Editors, customers, content teams: they upload whatever came off the device, and asking them to resize first is a battle nobody wins. Transforming on request means the source dimensions stop being your problem.
What adopting one changes
Adopting an image CDN is mostly a URL change. Your image references point at a new hostname and carry parameters describing what you want:
https://images.yoursite.com/photos/hero.jpg?w=800&fit=cover&fm=avifWith Small Pics the originals stay where they already are. It reads from S3, Cloudflare R2, DigitalOcean Spaces, Hetzner Object Storage, or any public HTTP origin, so there is no migration and no second copy of your library to keep in sync.
Three things are worth setting up properly at the start, because retrofitting them later is tedious.
Put the images on your own subdomain, something like images.yoursite.com, rather than the vendor’s hostname. Every image URL in your templates and in Google’s index then belongs to you, and switching providers later becomes a DNS change instead of a find-and-replace across the codebase.
Settle on a small set of widths and reuse them everywhere. Each distinct width is a separate cached variant with its own first-request generation, so a codebase where every component invents its own numbers pays for more of those than it needs.
Write real srcset markup rather than requesting one large size and letting the browser scale it down. Without it, the transformation buys you a smaller file than the original but still the same file for every device, which throws away most of the benefit.
If the category itself is still fuzzy, what is an image CDN defines it properly before getting into configuration.
Frequently asked questions
- Is an image CDN a replacement for a regular CDN?
- Not a replacement so much as a superset for one file type. Image CDNs include edge caching and distribution, so images served through one get the same distance benefit, plus transformation. Your other assets still go through your regular CDN.
- Can I put an image CDN behind my existing CDN?
- Usually you point image URLs at the image CDN directly rather than layering one in front of the other. Stacking two caches means two sets of cache rules and two places to purge when something changes.
- Does a regular CDN compress images?
- Some apply generic compression to responses, which helps with text but does little for formats like JPEG that are already compressed. Changing dimensions or converting to AVIF is a different operation, and a plain CDN does not do it.
- If my images are already optimized, do I need an image CDN?
- Less so. If every image is exported at exactly the size it will be displayed and already in a modern format, a regular CDN handles the delivery. The problem an image CDN solves is that images usually are not in that state, especially when other people upload them.
- Which one improves page speed more?
- They fix different causes. A regular CDN reduces the time spent travelling. An image CDN reduces how much travels. On an image-heavy page, payload size is often the larger share of the problem.