Performance optimization with website compression

This in turn includes not only the design of the page and uncomplicated handling, but above all a high loading speed. Because the higher the loading speed, the higher the conversion rate, i.e. the number of customers who decide to buy. According to eStrategy Magazin, mobile websites that load in five seconds instead of 90 seconds generate up to twice as much revenue. In other words, if the online shop is too slow, sales will decline.

But how do you achieve a high loading speed that turns the visitor into a customer? There are many approaches, in this blog we will highlight the possibilities of website compression with various tools and technologies.

Why website compression?

Web pages consist on the one hand of various text files, such as the actual HTML page, and on the other hand of so-called binary files, such as images or videos.

Both text and binary data can be reduced in size to improve website transmission and reduce data usage. This can be particularly helpful when using the website on the move, as mobile phone tariffs with limited data volumes are still largely prevalent in Germany and bandwidth can vary greatly depending on reception. Good compression can speed up the website and greatly improve the user experience even in such cases.
This also applies if the server is the limiting factor or many terminals share a connection.

Compress text files

For text files, there is a simple way to reduce the file size. Spaces and line breaks that are not necessary are removed, whereby this is usually done by the application itself. However, this has the disadvantage that the source text is no longer easily readable for humans. However, this does not change anything about the function itself.

Compress binary files

With binary files, however, such a conversion is not possible. For this reason, lossy compression is usually used for images and videos, i.e. the quality of the files is slightly reduced, but this is not perceived by the human eye.

Additional reduction of images is possible by removing metadata. In addition, an efficient image encoder, such as MozJPEG or Guetzli, can be used, which can also reduce images without additional loss of quality.

Alternatively, modern image formats such as WebP, AVIF or HEIF can be used, saving images more efficiently.

The WebP format is now supported by almost all browsers. For older browsers it is possible to deliver the pictures in a different format using the “picture tag”.

The AVIF format is not yet very widespread and is so far only supported by Chrome and Opera. With the next version 86, however, Firefox support is also planned.

The proprietary HEIF format (note: "proprietary": a format developed by the manufacturer that can only be used in a restricted way or requires licence fees) is currently not yet supported by web browsers.

Regardless of the image format, an additional compression is carried out by the respective web server during the transfer of the files, which, however, only has a minor effect on the size.

Since this compression does not change the image information in principle, the browser can restore the files 1:1 after transmission.

Excursus: Lossless compression

Lossless compression is based on two components: On the one hand, character strings that occur several times are replaced by references to a dictionary. On the other hand, individual characters are saved more memory-efficiently, e.g. with the so-called Huffman coding.

Classic text encodings, such as UTF-8, use fixed bit widths of 8 for a single character or use a multiple of 8 bits to represent special characters or umlauts, for example. Huffmann encoding, on the other hand, uses a dynamic length of bits for a single character. The technique is based on representing very frequently occurring characters with very few bits and rarely used characters with many bits.

For this compression, the gzip algorithm (DEFLATE) has become established in recent years and is supported by all common browsers and web servers. While there are clearly more efficient compression algorithms such as bzip2 or lzma, what speaks in favour of gzip is that both compression and decompression are carried out very quickly, which is extremely important for the transmission of web pages.

Image compression with Brotli

As an alternative to gzip, the Brotli algorithm was introduced in 2013, which was developed by Google employees Zoltán Szabadka and Jyrki Alakuijala.

Brotli works in a similar way to gzip and also uses Huffman coding and the dictionary technique LZ77. In contrast to gzip, however, other techniques such as context modelling are used here. In addition, there is a fixed dictionary with 13,000 entries of the most common expressions from texts and HTML documents.

The additional techniques make Brotli about 20 % more efficient than gzip at the same speed.

If a web server does not have Brotli support, the website will still be displayed correctly, as browsers generally agree on a common compression.

Brotli, by the way, is - like many modern web technologies - only supported via HTTPS encrypted connections.

Brotli and Magento

Since compression is independent of the software used, nothing special needs to be taken into account with a Magento online shop.

In a test, we tested the size of a category page of the Magento 2 demo installation with and without Brotli. The evaluation shows that the total size of the page, including all assets, is reduced by about 5 % by using Brotli.

Brotli and Shopware

As with Magento, nothing needs to be taken into account when using Brotli in a Shopware shop. But also like the Magento shop, a Shopware shop can benefit from Brotli.

As our test shows, the files of a category page of Shopware 6 with demo data were altogether about 4 % smaller than with gzip.

Brotli and Varnish

Varnish does not yet offer native support for Brotli. It is possible to deliver compressed files from the web server to Brotli via adjustments to the VCL file, but this overrides the logic for cache emptying of the application. Therefore, in this case, the corresponding logic must also be adapted. Some hints on this can be found in a tutorial by getpagespeed.

At the moment, neither Magento nor Shopware can generate a VCL file that supports Brotli. However, since an automatic fallback to gzip takes place, the lack of Brotli support is not a problem at this point.

With a customised VCL file, it is generally possible to benefit from Brotli with Varnish in some cases. Since the speed advantage as well as the additional visitor capacities of Varnish are significantly higher than those of Brotli, you should refrain from deactivating Varnish in favour of Brotli.

Static compression with Brotli

In addition to the dynamic on-the-fly compression of the web server, it is also possible to compress files that change only infrequently and are identical for all users once and then deliver these files.

This is particularly useful for JavaScript and CSS files that change only rarely. Such compression can then be carried out during deployment, for example. To do this, the command line tool "brotli" (not to be confused with the algorithm "Brotli") can be used.

If, in addition to the "normal" assets, the versions compressed with Brotli are also in the same folder, these are automatically used by NGINX. If Apache2 is used as the web server, it is necessary to adapt the .htaccess file and add a corresponding rule. Under Apache2, this even works with older web servers without mod_brotli.

Brotli compression at maxcluster

At maxcluster, all installed clusters have been delivered with Brotli support since the end of January (note: for Ubuntu clusters, the tool will be activated at the beginning of March). No further action is required for website developers to use Brotli.

For Apache, an official solution from Apache is available with “mod_brotli”. We have already activated the standard Apache installation supplied for Ubuntu 20.04 clusters for our customers. For Ubuntu 18.04. cluster we have compiled the module and will deliver it to our customers at the beginning of March.

For NGINX, a module is available directly from Google. Due to the lack of ready-made binary packages, we have already activated these for our customers and created corresponding Debian packages for the respective NGINX version.

By the way: You can easily find out whether the transmission via Brotli works via the browser tools. If content-encoding br is specified, the transmission takes place via Brotli.

Conclusion

In order to make optimal use of all the advantages of Brotli, it may be necessary to adapt an existing Varnish configuration and the deployment of your own shop. However, this minimal additional effort is worth it, as Brotli improves the performance of websites.

Published on 24.02.2021 | JH