How an Image CDN Works Behind the Scenes

Between a browser asking for an image and the image appearing, an image CDN does four things: works out what was asked for, finds the original, produces that version, and remembers it. Understanding that sequence explains most of the behaviour you will observe, including why the first load feels different from the rest. If you are still deciding whether you need one, start with how to choose an image CDN.

The request

Every image on a page is a URL, and with an image CDN that URL carries instructions. A request ending in w=800&fm=avif asks for an 800 pixel wide version encoded as AVIF.

So the URL is not a filename pointing at something that exists. It is a description of a file you would like to exist. Change one number and you have described a different image, which is why every width ends up a separate URL, stored separately.

Finding the original

The service looks for a cached copy of exactly that description first. If it has one, it sends it and nothing else happens. This is the common case on a site with any traffic at all.

If not, it goes to the origin, meaning your storage. A pull-based service reads whatever you already have without requiring you to move anything, which is why adopting one is not a migration.

Doing the work

With the original in hand, the operations run in sequence: crop to the region requested, resize to the dimensions asked for, apply adjustments, then encode into the requested format at the requested quality.

Encoding is the expensive part. AVIF compresses far better than JPEG by working harder at it, analysing the image more thoroughly to find the savings, and that costs processing time. The cost is paid once per variant, at the edge rather than on your server.

Which is why the first request for a variant is slower than the rest. Something real is happening, once, for a file that may go on to be served thousands of times.

Remembering it

The finished image goes back to the browser and a copy stays at the edge location that made it. Every later request for that URL is answered from storage, without contacting the origin and without running the encode again.

Your origin therefore sees very little traffic. The overwhelming majority of requests are answered from cache without reaching it at all, so a traffic spike lands on the CDN rather than on your server or your storage bill.

The flip side is that changes are not instant. Replace a photo but keep the filename and the old cached copies are still out there. Purging clears them and forces the next request to start over, and a cached copy already sitting in a visitor’s browser will persist until its own expiry regardless.

What this means in practice

Three things follow that are not obvious from the outside.

Requesting many sizes is cheap in storage but not free in time. Each width is a variant with its own first-request cost, so asking for eight where three would do means eight rounds of that work.

Be consistent about the numbers. w=800 and w=801 are separate variants, cached separately, each paying its own generation cost. A small set of standard widths, reused everywhere, keeps the cache dense.

And nothing is made in advance. A variant nobody asks for never gets generated, so adding a format or a size costs nothing until something actually requests it.

If the category itself is still fuzzy, what is an image CDN defines it from the ground up. And since the encoding step is where most of the saving comes from, AVIF vs WebP covers which format to ask for and why.