Do You Need an Image CDN?
Image CDNs solve a real problem that most small sites do not have. When the monthly fee is worth it, and when it is not.
An image content delivery network (CDN) is worth the monthly fee when your catalogue changes constantly, when you serve many variants of each image, or when you cannot control what gets uploaded. If your images change rarely and you know their display sizes, you are paying every month to solve a problem you could solve once.
An image CDN resizes, reformats and caches images on demand, generating whatever size and format each visitor needs from a single original. That is genuinely useful under the right conditions and unnecessary under others, and the difference comes down to how often your images change.
What an image CDN actually does
An image CDN performs 3 jobs: it resizes on demand, it converts formats per browser, and it caches results near the visitor. Each job replaces work you would otherwise do in advance.
Resizing on demand means one original produces every variant through parameters in the address. Format conversion means the same address returns AVIF to a browser that supports it and JPEG to one that does not. Caching means the second request for any variant is served from a location close to the visitor rather than from your server.
When a CDN earns its cost
- User uploaded content. You cannot control dimensions or formats when visitors upload the files.
- Large changing catalogues. A shop adding hundreds of products a month cannot process each batch by hand.
- Many variants per image. A design needing 6 sizes of every photograph multiplies manual work by 6.
- Global audiences. Serving visitors on other continents benefits from edge caching regardless of image handling.
- Teams without a workflow. Where several people publish and nobody follows a specification, automation is more reliable than instruction.
When a CDN is unnecessary
A site with a stable image library and known display sizes gains almost nothing from an image CDN. The optimisation happens once, and the files stay optimised indefinitely.
Marketing sites, portfolios, documentation, blogs and small shops usually fall into this group. The images change a few times a year, the layout is fixed, and the display sizes are known. Processing the library once and serving it from existing hosting achieves the same result as a monthly subscription, with fewer moving parts and no third party in the delivery path.
Comparing the 2 approaches
| Factor | Image CDN | Processed in advance |
|---|---|---|
| Ongoing cost | Monthly fee, usually usage based | None |
| Setup effort | Moderate, requires integration | Low, one batch |
| Handles new uploads | Automatically | Requires the same process each time |
| Format conversion | Automatic per browser | Decided once, with fallbacks |
| Works if the service fails | Images may not load | Images load from your own host |
| Suits changing catalogues | Very well | Poorly |
| Suits stable libraries | Overkill | Very well |
The dependency worth thinking about
An image CDN sits in the delivery path, so an outage or a billing problem can remove every image on your site at once. The risk is small and the consequence is total.
Pricing changes carry a similar weight, since moving away from a service whose addresses are written into thousands of pages is harder than adopting it was. Where a CDN is the right choice, keep the original files under your own control and avoid building addresses that only one provider can serve.
How to decide
To choose between the 2 approaches, answer these 5 questions.
- How often do your images change? Weekly or more often favours a CDN.
- Do visitors or staff upload images without following a specification? If yes, favour a CDN.
- How many sizes does each image need? More than 3 favours a CDN.
- Is your audience concentrated in one region or spread globally? Global favours a CDN.
- Could one person process the whole library in an afternoon? If yes, do that instead.
Most small and medium sites answer the last question with yes, which settles the matter. Revisit the decision when the catalogue grows past what you can process by hand.
What you still have to do with a CDN
A CDN does not decide the display size, and serving a correctly sized image remains your responsibility. Requesting a 3000 pixel variant for a 600 pixel slot wastes bandwidth exactly as before.
The service also works from whatever original you supply, so a poorly compressed or wrongly cropped source produces poor variants. Uploading a good original matters under both approaches. What a CDN removes is the repetitive work of generating sizes, rather than the need to think about them.
What image CDNs typically cost
Pricing is usually based on the number of unique transformations, the bandwidth served, or both, which makes costs unpredictable on a site with traffic spikes. Free tiers exist and are commonly exceeded by the first busy month.
Two details catch site owners out. Each combination of size, format and quality counts as a separate transformation, so a responsive design requesting 4 widths in 3 formats generates 12 billable variants from one photograph. Cache expiry then regenerates some of those variants later. Model the cost against your real image count and variant count rather than against the headline price.
A hybrid approach that works well
Process your fixed images in advance and route only user uploaded content through a service. Most sites have both kinds and treat them identically, which is where the waste appears.
Marketing pages, product photography and article images rarely change and can be optimised once. Customer review photographs, profile pictures and community submissions arrive constantly at unpredictable sizes and genuinely need automation. Splitting the 2 keeps the subscription small, since usage based pricing then covers a fraction of your images rather than all of them.
The middle option most sites overlook
Most content systems generate multiple sizes on upload already, which is a CDN feature you may be paying twice for. WordPress, Shopify and most site builders create several variants automatically.
Check what your platform does before subscribing to anything. If it already generates responsive sizes and serves WebP, the remaining benefit of a CDN is edge caching and format negotiation, which matters far less on a site with a regional audience. Testing this takes 2 minutes and occasionally removes the need for the subscription entirely.
Bandwidth costs on your own hosting
Properly sized images reduce hosting bandwidth by 60 to 90 percent, which frequently removes the cost argument for a CDN. Sites reach bandwidth limits because of oversized images rather than because of visitor numbers.
Work out the current figure before assuming a CDN is needed for capacity. A site serving 4 MB pages to 10000 visitors a month moves 40 GB. The same site serving 800 KB pages moves 8 GB, which fits comfortably inside almost any hosting plan. The optimisation solves the capacity problem and the speed problem together.
Processing a library instead of subscribing
Convert and resize the library once, serve it from your existing host, and revisit the decision when the catalogue grows. The work takes an afternoon for most sites and does not repeat until the design changes.
Drop up to 500 files in at once, or drag a ZIP archive straight in, and set the width, format and size target for the whole set. Everything runs inside your browser on your own processor, so client libraries and unpublished assets never reach a server. No subscription starts, no third party joins your delivery path, and the files remain entirely under your control.
Write down the settings you used, including the widths, the format and the quality number. The next batch of images then matches the existing library without anyone having to work out the specification again, and a new person joining the team has a rule to follow rather than a judgement to make. That written specification is what an image CDN sells, and on a stable site it costs nothing to maintain yourself.