This article was sponsored by Cloudinary. Thank you for supporting the partners who make SitePoint possible.
When adding images to a website, most of us will instinctively know to avoid using a GIF for a photo and avoid using a JPEG for a graph. The lazy ones among us – i.e., me – may just opt for PNG for everything and hope for the best.
So why do we do this? It all comes down to the encoding used to create the image in a particular file format. JPEG suits photography (the “P” stands for “Photographic”) since it blurs sharp edges but preserves smooth gradients. Encoding an image with large, sharply-defined blocks of color using JPEG causes loss of definition and inefficient encoding.
Conversely, GIF suits logos or simple block graphs, since it focuses on the changes between uniform regions of color. This is obviously pretty useless for photos, where the colors differ almost pixel by pixel.
As an example, this image comes in at 106Kb as a JPEG:
However, it reaches a whopping 517Kb encoded as a GIF. That’s almost 5 times bigger just by using an inappropriate image format. Oh dear.
It manages to hit 329kb encoded as a PNG. Although not quite as bad, this is still over 3 times bigger than when using the most appropriate format for the image contents.
As we can easily see here, the main image formats are best suited to different types of content and choosing the wrong format for the image causes potentially significant, unnecessary bloat.
You have to make sure that each image going on to your website is encoded in the most appropriate format, and not just the format in which you received it, in order to avoid unnecessary page bloat.
So far we’ve just covered the three “classic” image file formats — the original flavors that everyone knows and loves. Here’s where it starts to get tricky: browsers are all pushing different next-generation image formats. Chrome has the fantastic WebP, Edge supports JPEG XR and Safari has JPEG 2000.
Browser Support for Next-Gen Image Formats
|WebP||JPEG XR||JPEG 2000|
WebP, for example, can give significantly better results than GIF, PNG, and JPEG in various scenarios. For the test image we’ve used above it comes in at 90.5Kb – a saving of around 15% from JPEG. However, you can currently only use this image type if the device requesting the image is Chrome, Opera, or the Android Browser.
JPEG XR is Microsoft’s own format – JPEG eXtended Range – and improves on basic JPEG encoding, even supporting transparency (like PNG and WebP). The test image in JPEG XR format weighs 104Kb: around 2% shaved off the original JPEG image. Naturally, this is only for IE9+ and Edge, and as the name suggests it is most appropriate for photographic images.
So not only do you have to ensure you’re using the most appropriate format for the image content, you also need to consider the most appropriate format for the device requesting the image. You might even need to create four or five versions of every image: one encoded in one of the classic three formats (for all devices), and one for each of the new, browser-specific, next-generation formats (to enjoy the optimization benefits of the new format). That’s a lot of time and effort.
Upcoming Image Formats
So far we’ve covered the “classic” formats that you can use in all browsers, and the impressive new formats available in some of the main browsers.
Uneven browser support means that if we want to take advantage of the new formats, we need to create multiple, alternate versions of each image on our site.
Now here’s a curve-ball: as-yet unsupported image formats. Formats like FLIF and BPG are in the wild, gaining traction, and it’s only a matter of time before one of the browsers rolls out support.
What does this mean for you? You may have to regenerate all of your existing images in a new format or two, requiring even more time and effort.
Cloudinary’s Auto Format
Learn PHP for free!
Make the leap into server-side programming with a comprehensive cover of PHP & MySQL.
RRP $11.95 Yours absolutely free
Happily, there is one great solution out there: Cloudinary’s “auto format” feature lets you upload one original image — potentially even in the least appropriate format for the content — and by using one clever URL parameter you can deliver it in the most appropriate format for the end user, even if a new format comes out in the future.
If we add the f_auto parameter into the image URL, the image format is now automatically determined by Cloudinary:
Viewing that URL in Chrome will give a WebP response; in Edge it will be a JPEG XR image. In Firefox it will be the original-flavor JPEG.
With this setting in your image references you will never have to worry about cross browser image format support — now or in the future. Extremely powerful, future-proofing stuff.
This content is sponsored via Syndicate Ads.
Robin Osborne is a web performance nerd, who is passionate about helping companies implement the most efficient solutions to optimize their product. He can be found speaking at conferences and user groups and running classes from basic to advanced .Net, MVC, Azure, Chatbots, and Web Performance. When he's not teaching his daughters to code, he can be found tracking down London's best coffee, one café at a time.
Jump Start Git, 2nd Edition
Visual Studio Code: End-to-End Editing and Debugging Tools for Web Developers