Best practices of image compression

Aleš Cankar13.02.2019eCommerce, Websites

It is well established that we must take good care of our website’s performance in order to achieve a good user experience and good rankings on search engines. One way of achieving better performance is by properly optimizing or, in other words, compressing the images. Let’s take a look at a couple of different scenarios and solutions, where we encountered the need for image compression while working on our projects Organic+, Iglu Šport and Intersport.

1. Organic+ and transparent backgrounds

While working on the website Organic+ we used .png images with transparent backgrounds and we noticed that the quality of the images was not what we were hoping for. My first thought was that the culprit was the image compression adapter used by default in Magento 2 – PHP GD2. While it works wonders with .jpg images and .pngs without any transparency, it more than struggles with those with transparency. While the size is perfectly acceptable, the resulting images appear to have gained unwanted jagged edges.

Take a closer look at the edges around the illustrations, the logo and the text on the bottle.

I’ve read beforehand that the alternate compression adapter is much better in terms of quality – ImageMagick to the rescue!

You can choose an Image Adapter on Stores → Configuration → Advanced → Developer

I asked our system admins to install the necessary php plugin `imagick`, after which I was able to select ImageMagick in Magento. If the plugin is not installed, the configuration will not be saved.

After flushing the image cache, I compared the results and was surprised by the difference. Below, you can take a look at the new, compressed image and compare it with the old one (above).

The same image, but compressed using ImageMagick adapter.

While the image quality improved dramatically, the image size, however, did not. In fact, the resized image could even become larger than the original image so naturally some post-processing was required.

I tried using the `optipng` program for image compression but the results were not what I was hoping for.

	GD2	Imagick	imagick + optipng
Banner image	63.6k	546k	546k
Thumbnail	12.2k	84.2k	84.5k

I used the maximum amount of compression by running the command

optipng -o7 -strip all *.png

but it only compressed the images by ~0.10%.

TinyPNG to the rescue!

TinyPNG developed an extension for Magento (1 and 2) that allows you to compress images before they’re first served and stores them on your server so they’re only compressed once (until you flush the image cache). This yielded very good results as the images were compressed by ~90%.

	Imagick	TinyPNG
Banner image	546k	33.7k
Thumbnail	84.2k	8.3k

The image quality is nearly perfect – you can hardly see any difference unless you ‘pixel-peep’ both images side by side.

Original image (317.4k @1000x750px)

Compressed image (115.5k @1000x750px)

Tip: you can enlarge one image by clicking on it and use arrow keys to move between them and inspect the differences

The catch?

The initial page load time is dramatically increased since the module must send the images to TinyPNG API and wait for the result. I did not measure the actual difference but it was large enough for it to be noticeable.

You only get 500 free compressions per month; a limit that is exceeded fairly quickly, even if your store doesn’t have many products (ergo images). In our case, there were 10 products, each with only one image used as a base image, thumbnail and all the rest. By only compressing each image once I reached 96/500 compressions per month.

If you provide your payment details, you can compress more images than 500 for a reasonable price, but the sum can quickly add up. Refer to the pricing table (as of February 2019) below:

No. of images	Price
0-500 per month	free
501–10000	$0.009 per image
More than 10001	$0.002 per image

2. Iglusport and jpegoptim

The problem we encountered with our project Iglusport was the fact that the client was used to uploading unoptimized images for the main banners and for the homepage content.

Here, we turned to jpegoptim, which is used to optimize/compress jpeg files. The program supports lossless optimization, which is based on optimizing the Huffman tables, and the so-called “lossy” optimization or lossy compression where, in addition to optimizing the Huffman tables, the user can specify the upper limit for image quality.

By default, jpegoptim modifies the input files (if they are optimized); in order to preserve original files use option -d to specify alternate directory for saving the optimized files as well. Only normal files are optimized, while symbolic links and special files are skipped. Also, any other hard links to the file, which are being optimized, are unaffected.

I asked our system admins to install the necessary php plugin `jpegoptim` and, when they were done, I was able to configure it and test the results.

We have added a watcher to the following folders (most of the client content images are here):

pub/media/wysiwyg pub/media/amasty pub/media/blog

We have used 80% compression and stripped all meta tags:

strip-all

Strip all markers from output file.

NOTE! By default, only Comment & Exif/IPTC/PhotoShop/ICC/XMP markers are kept, everything else is discarded.

It is likely that the output JPEG will still contain one or two markers (JFIF and Adobe APP14), depending on colorspace used in the image, as these markers are automatically generated by the libjpeg encoder.

80% quality

This sets the maximum image quality factor (and disables lossless optimization mode, which is enabled by default). This option will reduce the quality of those source files that were saved using a higher quality setting, while the files that already have a lower quality setting will be compressed using the lossless optimization method.

Results

	Before	After
Page size	6MB	3.9MB
Load time	2.52s	1.69s

Before the image compression

After the image compression

Breakdown of content type after the image optimization.

3. Intersport & uploading images

With Intersport, we decided to use high-resolution images so the website looks nice on modern high-DPI (dots per inch) devices, such as tablets and mobile phones. However, this resulted in a slower page load time. Images are one of the most common multimedia elements we encounter while browsing the web so it’s no surprise that they (can) constitute a major part of the website’s size. < img/ >‘s srcset attribute allows us to present multiple versions of the same image to the user (device). The device will then decide which version to download according to its display DPI, signal strength and so on.

How to tackle the problem?

When preparing graphical content for your website (banners and other material), you should prepare 3 versions of the same image. A normal sized image for desktops (with low DPI) with 1440 pixels width for full-width image (the height is determined by the desired aspect ratio), another version twice its width; in this case 2880 pixels (remember, doubling the width will result in a 4x bigger size), and a small image for smaller screens (720px).

Markup

In order to display these images we must provide a srcset and sizes attributes besides the regular src attribute.

Example:

img src="{{media url='wysiwyg/ow/CMS/jack_wolskin_helium_intersport_1440x780.jpg'}}" sizes="(min-width: 1460px) 1440px, 100vw" srcset="{{media url='wysiwyg/ow/CMS/jack_wolskin_helium_intersport_2880x1560.jpg'}} 2880w, {{media url='wysiwyg/ow/CMS/jack_wolskin_helium_intersport_1440x780.jpg'}} 1440w, {{media url='wysiwyg/ow/CMS/jack_wolskin_helium_intersport_720X390.jpg'}} 720w" /

In this case, we have an image named jack_wolskin_helium_intersport_1440x780.jpg for normal displays, jack_wolskin_helium_intersport_2880x1560.jpg for high-DPI displays and jack_wolskin_helium_intersport_720x390.jpg for low resolution displays. Please note that providing the resolution in the file name is not required but it is recommended for it to be easily distinguished. However, what is required are the 2880w, 1440w and 720w labels after the filenames. This tells the browser the actual size of the image and, based on this, it will decide which image to load.

Additionally, we must also add the sizes attribute. This tells the browser how big the image container will be with different resolutions. In this case (the top slider) the container is always 1440px wide with the resolution of 1460px (and more) and “full-width” (100vw) below that resolution. The browser therefore knows which image to load before even loading it. It knows the size of the container and it knows the available sizes to choose from.

You can read more about this topic on the Google’s developers page.

Real world example

I added 3 images on the slider (for each slide) – 1x, 2x and 0.5x. When viewing the page on a very small screen, the smallest image is used:

However, as I increase the window size, more appropriate images are loaded:

This way, the best image for the current viewing scenario is used.

Backwards compatibility

As this is a relatively modern feature, it is expected that it will not be supported by all browsers and versions. However, the nice thing about this feature is that the fallback is always implemented. If the user’s browser does not support the srcset and sizes attributes, it will just load the image in the src attribute and nothing else.

Additional notes on image compression

When editing CMS page’s content or block’s HTML content, you should use some other text editor for a couple of reasons:

You can expect better formatting, syntax highlighting, etc.
In case you make a mistake, it’s easier to find and fix it (because of the formatting and highlighting).
In case you mess up and need to revert your actions, you can just undo the changes and go back to the original version. :)

Steps:
1. Open the CMS page/block you want to edit.
2. Click on “Show/Hide editor” so you see HTML in plain text.
3. Copy the entire content to a text editor (recommended: Atom, Brackets, Sublime, notepad++, etc.).
4. Make your changes.
5. Copy the content back to the editor and save.

Conclusion

Remember that these are just three recent examples in our struggles with web performance in terms of image optimization and image compression. There are many more routes you can take; some of them worse than others. At the end, it all comes down to your particular scenario, which can vary depending on the platform you use, the types, sizes and quantity of images you have and much more. If you want to learn more about general performance improvements in Magento 2, you should also read our article explaining performance tests, tips, improvements and hacks.

However, if you’re filled with questions or if you need help with optimizing the images on your website, simply write to us and together we’ll optimize your website or online shop!

Aleš Cankar

Web Developer

I met the world of WordPress programming as a self-thought freelancer and later, at Optiweb, I further upgraded my knowledge and I soon faced my role as a Magento frontend developer.