3 Popular ways of compressing images for the modern Web
According to a report, of all the web page traffic, 65% of bandwidth is consumed by images during a load of a typical web page. This makes us realize how important it is to optimize the image size while maintaining its quality. Let’s see what choices we have to serve these images and photos.
One way is to use Lazy loading of images or other resources, which is now well known and used by many site owners. While it can defer loading non-critical resources on the page, the size of resources will still be the same and can break the experience for users on a slow network or can add to bills for metered connection.
Another way is to use an appropriate image format. There are hundreds of image file types and some of them are very popular on the web including JPEG, PNG, GIF, etc. Most of these common image formats are based on technology that is now a few decades old. For example, if we talk about JPEG, which is a very common and most widely used lossy image compression format even in the current era was developed in 1992, 28 years ago. It was adopted by web developers and digital camera manufacturers as a default choice for storing images as the compression algorithm was most suitable for images and photographs where the content has smooth variations of tone and color.
Page Contents
So, what is new?
Way back in 2010, a team at Google came up with another research where they found a better compression can be achieved for lossy images, and in a trial of around 1 million images, they could achieve a savings of 39% without compromising the visual quality. The new format was named WebP and with this promise, they made a tool available for developers to convert images to WebP format and also started supporting the new format in the WebKit engine.
WebP lossy images are 25-34% smaller than comparable JPEG images at equivalent SSIM quality index.
Do I need this?
There are high chances you might already be using images on your page. If yes, you can head on to PageSpeed Insights and check the potential savings this can bring under the ‘Opportunities’ section.
Impressed. How to achieve this?
Most popular browsers including Google Chrome, Microsoft Edge, Firefox and Opera support this. Besides these, any browser which is based on the WebKit engine has native support for WebP. You can check current browser support here. As there are many browsers that do not support this format, the implementation is not straightforward. However, if you are using RabbitLoader, you may skip the below section as this is taken care of in a very robust way for our users.
Here are some ways you can choose to detect browser compatibility before serving the image. But in all three scenarios, you need to take care of the conversion of the source image to WebP format.
- You can read the “Accept” headers sent by browsers to check the support and serve the image accordingly. If image/webp is present in the “Accept” header value sent by the browser to the server, your backend or server-side script can server WebP content. Rabbit Loader uses this method to detect browser support and serve the original image as a fallback for non-supported browsers.
- The HTML
<picture>element can be used to provide many sources for a single picture. Here you can add WebP format along with JPEG, PNG or other formats. The browser will choose the best match to display the image. If you want to explore this, go through the MDN guide for the picture element. - Once a page is loaded, run a JavaScript from Modernizr or a similar library to detect image formats supported by the browser and then change the URL in the “src” attribute based on the result. This technique is not recommended as it will introduce a significant delay in loading images and may increase CLS because the page is already rendered.
For RabbitLoader users, we have added this as an opt-in feature where images are optimized without site owners putting any extra effort. Once enabled (See: how to enable image conversion to WebP), images used in a webpage can be automatically converted to WebP on the fly to boost page loading time and speed index. If the encoding is not supported by the browser, automatic fallback happens to the original source.