Why your images belong on a CDN (and what an image CDN adds)
Images are usually the heaviest thing you ship and the easiest big win you are not taking. What a CDN fixes, and the four things an image CDN does that a plain one does not.
Open DevTools on almost any page, sort the network panel by size, and look at the top ten rows. On the overwhelming majority of sites they will all be images, and the first one will be several times larger than anything else.
That is genuinely good news, because it means the biggest lever available to you is also one of the easiest to pull — and unlike JavaScript, images can be optimised entirely without touching your application code.
Two separate problems
Images are slow for two unrelated reasons, and confusing them is why people are disappointed by half-measures.
They are far away: a 400 KB photo served from one origin takes as long to reach Sydney as any other 400 KB does, which is a while. And they are too big: the wrong dimensions, the wrong format, quality settings nobody chose.
A plain CDN fixes the first problem completely and the second not at all. It will deliver your unnecessarily enormous photo very quickly indeed. That is worth having — but it is half the available win, and usually the smaller half.
The four things an image CDN adds
1. Resizing per request
The largest single saving, and the least glamorous. A 3000-pixel photo displayed in a 400-pixel card carries roughly 56 times the pixel data being shown. Resizing to what is actually displayed — around twice the CSS dimensions, for high-DPI screens — routinely removes 70 to 90 percent of the bytes before any format conversion is considered.
2. Format negotiation
Browsers advertise which image formats they accept on every request. An image CDN reads that header and serves AVIF to clients that support it, WebP to those that do not, and the original to anything older — deciding per request, with no <picture> element to maintain and no build step to keep in sync.
3. Transforms driven by the URL
This is the part that changes how you work. Rather than generating variants ahead of time, you request the variant you want as part of the URL — a width, a crop, a quality setting, a format override. The edge produces it on first request and caches the result, so subsequent requests for the same variant are ordinary cache hits.
The practical effect is that your media library holds one high-quality original per image and nothing else. No thumbnail regeneration, no rebuilding when a designer changes a card width, no orphaned derivative files accumulating for years. A layout change becomes a change to a number in a URL.
4. Delivery from nearby, with everything cached
The transformed result is cached at the edge like any other object, so the conversion cost is paid once per variant rather than per request.
Why this beats a build-time pipeline
Generating image variants at build time works, and works well, right up until it meets a CMS.
Build pipelines break down because content is not built. Someone uploads a 4000-pixel product photo through the admin panel on a Friday afternoon, and no build runs. A designer changes a grid from three columns to four, and every pre-generated width is now wrong. A new device category arrives and there is no variant for it. Each is individually manageable and collectively the reason most sites' image optimisation quietly stops working within about eighteen months of being set up.
On-demand transformation does not have this failure mode, because there is nothing to keep in sync. The correct variant is whatever the URL asks for.
This is usually the fastest available route to a better Largest Contentful Paint, because the LCP element on most pages is a large hero image. Optimising that one image frequently moves a Core Web Vital from red to green in an afternoon — which is not something you can say about many performance changes.
The three things to get right in your HTML
The edge handles the bytes; a few markup details determine whether the browser makes good use of them.
- Use srcset and sizes so a phone requests a phone-sized image rather than downloading the desktop one and scaling it down. Without this, resizing only helps the visitors who happen to be on small screens.
- Set width and height attributes on every image. It costs nothing and prevents the layout shift that occurs while the file is still arriving.
- Never lazy-load the LCP image. Lazy loading below the fold is a genuine saving; applying it to your hero image delays the exact element Google is measuring. Check that your CMS is not adding
loading="lazy"to everything indiscriminately.
Frequently asked questions
What is an image CDN?
An image CDN is a content delivery network that also transforms images on request — resizing them, converting them to modern formats such as WebP or AVIF, adjusting quality and cropping — and caches the results at the edge. You store one high-quality original, and each visitor receives a version appropriate to their browser and the space the image occupies.
Should I put my images on a CDN?
Yes, for almost any site with visitors outside your server's immediate region. Images typically account for most of a page's total weight, so serving them from a nearby edge produces the largest single improvement in load time available. Adding on-the-fly resizing and format conversion compounds it, since distance and file size are separate problems and a plain CDN only addresses the first.
How much can image optimisation reduce page weight?
Frequently by 80 to 90 percent for the images themselves. A 2.4 MB photograph resized to its displayed dimensions might drop to around 900 KB, and converting that to AVIF can take it under 200 KB. The resize normally accounts for more of the saving than the format change, since oversized images are extremely common.
Is an image CDN better than generating images at build time?
For sites with content managed through a CMS, generally yes. Build pipelines require every needed variant to be known and regenerated in advance, which breaks when someone uploads an oversized image outside a build or a designer changes a layout width. On-demand transformation has nothing to keep in sync — the required variant is whatever the URL requests, generated once and then cached.
Do I still need srcset if I use an image CDN?
Yes. The CDN can produce any size you request, but only the browser knows the viewport, the device pixel ratio and the layout. srcset and sizes are how the browser tells the CDN which size it actually needs. Without them, every device requests the same image regardless of screen size, and much of the benefit of on-demand resizing goes unused.
Images are the heaviest part of most pages and therefore the biggest available win. A CDN fixes the distance; an image CDN also fixes the size, by resizing and converting per request and caching the result. Upload one original, request variants by URL, use srcset so browsers ask for the right one, and keep your hero image out of lazy loading.
See how NordicCDN does this for your site:
Mads has worked in IT — mostly hosting — since he was 16. He took an early stake in a SaaS company and helped grow it through to its acquisition by Visma, has built and run data-center networks, and served as CTO of a Danish data center. He started NordicCDN to make fast, secure infrastructure simple to use.
