Handling website images, videos and audio files through a digital asset management solution, like Cloudinary, offers the huge advantage of optimising download speed.
It's always worth first considering whether your content really is enhanced by an image. Pages without them will always download quicker - that's obvious - but assuming you do need them, how to get them delivered at the lowest cost possible?
Part of the “cost” is to your visitors. Not all of them will be on high-speed network connections; some will be reading your pages on mobile phones perhaps on mobile networks, perhaps using older devices with reduced CPU capacity. With the majority (and an increasing amount) of web content now consumed on mobile devices, the aim should always be to deliver media at the lowest bandwidth cost possible.
Moreover, it's an ecological imperative to minimise the amount of computing and network resources involved in media delivery. Cloudinary set an excellent example in this regard, and that, coupled with their outstanding support and product make the company an obvious media delivery choice.
There's also a cost to the website builder. How do you reduce bandwidth to the greatest effect with the least effort? Should you use the <picture> element? What about <img srcset>? What about reducing dimensions or using modern image formats like AVIF?
There's a lot of complexity here and not everyone has the time and background knowledge to delve too deeply into it. Personally, and this is probably heresy, I don't care much for solutions that cross the boundary between HTML and CSS, where you have to associate specific media files with target viewport widths or pixel densities.
Currently, the path to least resistance has to be in how you declare the source media file in your <img>, <video> and <audio> elements. In other words, manipulating the URL in order to directly effect download bandwidth.
Before we see how to do this in Cloudinary, can you tell the difference between these 2 images?
Me neither, but the first one is the original 2.6MB image, while the one on the right is the same image resized to 360 pixels and compressed to 80% quality resulting in a delivery size of 38KB.
So, for a thumbnail image we get visually the same quality at a small fraction of the original size.
What happens if we show the same image in larger containers? We should expect the reduced size image to lose some crispness.
And indeed, the smaller sized image is a bit fuzzy but still looks pretty good.
An increasing number of people use their mobile devices to access websites.
Website visitors using their data plans to browse the internet will be a lot happier paying $0.038 instead of $2.60 and happier still that their mobile phones are using far less battery power to download and decode the smaller image.
For these reasons, the CMS application deploys sites that automatically serve optimised media files.
By default, the CMS forces media file to be served from Cloudinary's CDN at 80% quality, scaled down to the smaller of 25% of the original width and 360 pixels.
In the example above, the width of the original photo is 4032 pixels, 25% of which (1008) is more than 360 - hence, “w_360” is requested in the image url. Cloudinary automatically scales the image down for us and serves the 38KB file from its CDN.
It may be that some websites do need to show best resolution images - photographer portfolio sites, for example. The CMS provides a MEDIA page collection type for this purpose, which shows a thumbnail of each image according to the same 25% / 360px rule that when clicked displays the image in full screen mode.
In full screen mode, images are loaded initially at the smallest dimension which is then automatically “upgraded” to the dimension that is closest to the viewer's viewport width. This has the rather pleasing effect of showing potentially grainy images with zero delay - they have already been cached when viewed as thumbnails - and then almost imperceptibly blossoming into the best resolution for the viewport.
Obviously, this quality upgrade doesn't happen when the visitor's device is 360px or less.
Depending on the device, laptop and desktop users will get either the original size image OR the size between original and LEAST(25%,360px). In this way, images are each available at 3 different dimensions, keeping the number of transformation credits used to a minimum whilst delivering optimal performance.
When original width images are served to larger viewports, Cloudinary still delivers the 2.6MB image in the example above optimised to 1.3MB.