You may already be familiar with the core concept of a content delivery network (CDN): a network of distributed but interconnected
servers that quickly and efficiently delivers assets to users. When a file is uploaded to a CDN provider, a duplicate will be created
on the other nodes of the CDN network around the world. When a user requests a file, the data will be sent by the node geographically
closest to that user, reducing latency. The distributed nature of CDNs also provides redundancy in the event of network outages or
hardware failure, and load balancing to mitigate spikes in traffic.
An
image CDN
can provide all these benefits, with one key difference: the ability to transform and
optimize the contents of an image based on strings the URL used to access it.
A user will upload a canonical, high-resolution image to the provider, which will generate a URL used to access it:
https://res.cloudinary.com/demo/image/upload/sample.jpg
Though the exact syntax used will vary from one provider to another, at a minimum all image CDNs allow you to alter a source
image's dimensions, encoding, and compression settings.
Cloudinary
, for example,
performs
dynamic resizing
of an
uploaded image through the following syntaxes:
h_
followed by the numerical height in pixels,
w_
followed by the width,
and a
c_
value that allows you to specify
detailed information about how the image should be scaled or cropped
.
Any number of transforms can be applied by adding comma-separated values to the URL, prior to the filename and extension,
meaning that the uploaded image can be manipulated as-needed through the
src
of the
img
element that requests it.
<img src="https://res.cloudinary.com/demo/image/upload/w_400/sample.jpg" alt="…">
The first time a user visits the URL containing these transforms, a new version of the image proportionally scaled to a
width of 400px (
w_400
) is generated and sent. That newly-created file is then cached across the CDN so it can be sent
to any user requesting the same URL, rather than recreated on-demand.
Though not uncommon for image CDN providers to offer
software development kits
to facilitate advanced usage and integration with various technology stacks, this predictable URL pattern alone allows us to easily
turn a single uploaded file into a viable
srcset
attribute without the need for any other development tooling:
<img
src="https://res.cloudinary.com/demo/image/upload/w_1000/sample.jpg 1000w"
srcset="https://res.cloudinary.com/demo/image/upload/w_1000/sample.jpg 1000w,
https://res.cloudinary.com/demo/image/upload/w_800/sample.jpg 800w,
https://res.cloudinary.com/demo/image/upload/w_600/sample.jpg 600w"
alt="…">
We're able to manually specify our desired level of compression using what should now be a familiar syntax:
q_
, short
for "quality," followed by the numerical shorthand for compression level:
<img src="https://res.cloudinary.com/demo/image/upload/w_400,q_60/sample.jpg" alt="…">
It's rare that you'll need to include this information manually, however, thanks to a set of incredibly powerful features
provided by most image CDNs: fully automatic compression, encoding, and content negotiation.
Automated compression
The computing power image CDNs have at their disposal means they're able to offer an incredibly powerful feature: analyzing
the content of an image to algorithmically determine its ideal compression level and encoding settings, just as you or I would
manually fine-tune compression for each one of our images.
These algorithms automate the decisions you might make balancing file size and perceptual quality, analyzing image content for
measurable signs of degradation and fine-tuning compression settings accordingly. This frequently means huge reductions in file
size compared to the one-size-fits-all manual approach to compression settings.
As complex as this process might sound, implementation couldn't be much simpler: for Cloudinary, the addition of
q_auto
in an
image URL enables this feature:
<img src="https://res.cloudinary.com/demo/image/upload/w_1400/sample.jpg" alt="…">
<!-- 250 KB-->
<img src="https://res.cloudinary.com/demo/image/upload/w_1400,q_auto/sample.jpg" alt="…">
<!-- 134 KB-->
Automated encoding and content negotiation
Upon receiving a request for an image, image CDNs determine the most modern encoding the browser supports through the
HTTP headers
sent by the browser alongside requests for assets?specifically,
the
Accept
header. This header indicates the encodings that the browser is able to understand, using the same
media types
we would use to populate the
type
attribute of a
<picture>
element's
<source>
.
For example, adding the
f_auto
parameter to the list of image transforms in an asset URL explicitly tells Cloudinary to
deliver the most efficient encoding the browser is able to understand:
<img src="https://res.cloudinary.com/demo/image/upload/w_1200,q_auto,f_auto/sample.jpg" alt="…">
The server then generates a version of the image with that encoding and caches the result for all subsequent users with the same
level of browser support. That response includes a
Content-Type
header
to explicitly inform the browser of the file's encoding, regardless of the file extension. Even though a user with a modern browser will make a
request for a file ending in
.jpg
, that request will be accompanied by a header informing the server that AVIF is supported, and the server
will send an AVIF encoded file along with an explicit instruction to treat it as AVIF.
The net result is a process that not only absolves you of creating alternately encoded files and of manually fine-tuning your compression settings
(or maintaining a system that does these tasks for you), but does away with the need to use
<picture>
and the
type
attribute to effectively
deliver those files to users. So, using the
srcset
and
sizes
syntaxes alone can still provide your users with images encoded as?for example?AVIF,
falling back to WebP (or JPEG-2000, for Safari alone), falling back again to the most sensible legacy encoding.
The drawbacks of using an image CDN are more logistical than technical, chief among them being cost. While it is common for image CDNs to
offer feature-robust free plans for personal usage, generating image assets requires bandwidth and storage space for uploads, processing on
the server to transform images, and additional space for the cached transform results?so advanced usage and high-traffic applications may require a paid plan.