Why is http compression so important?

About http compression

At the moment, the two most-used compression techniques are Brotli (.br) and GZIP (.gz). Lots of browsers support GZIP compression, but the Brotli compression has a higher compression ratio, which generate smaller file sizes.

The most efficient approach is to code using a priority matrix. If the client browser supports Brotli, you use this coding as standard. Not the case? Then you use GZIP. When it comes down to it, compression is simply a technique for retaining bandwidth. If the browser doesn’t support compression at all, you use the uncompromised files.

Why use http compression?

Most PWAs use HTML, JavaScript or CSS files. These files can vary from a few kilobytes to hundreds of kilobytes. Http compression is essential for optimising applications’ loading times if the internet is slow, such as a slow 3G connection.

Imagine you have a JavaScript file of 900 kilobytes and the client has an internet speed of 300 kilobytes per second. This would make the loading time three seconds. Let’s calculate this loading time when using http compression. In an ideal situation, the customer’s browser supports Brotli. Thanks to Brotli’s high compression ratio, the compromised JavaScript file is just 200 kilobytes. The loading time for this file has therefore fallen from three seconds to 0.67 seconds! And remember – this is without adapting the file.

When should you use http compression?

Applications’ loading times improve considerably with http compression, although the setup is relatively simple. So, http-compression is pretty much essential when you have long application loading times and the related low performance. You’ll find applications online that will let you measure the most important factors of your PWA.

Synergistic improvements

http compression works even better alongside other optimisations. If you optimise the right key factors, they reinforce one another. Examples include:

• Reduce the original size of your HTML, JavaScript or CSS files.
• Use the ‘swap’ value for the ‘font display’ option in CSS files.
• Translate images into their next-gen format. I have personally not come across a single scenario in which I translated a PNG file with a high resolution of 5 MB into WEBP. The translated file was 200 kilobytes. This means the loading time of 300KB/s fell from 17.1 seconds to 0.67 seconds!
• As far as possible, load applications as ‘lazy’. Imagine: you have a log-in page and a user profile. Users have to log in before they can look at their profiles. The CSS needed for the user’s profile does not have to be loaded as long as the user is still on the log-in page. You could therefore use a non-blocking pre-loading strategy to improve the user experience.
• Use service workers wherever possible. A service worker can cache an application file. It can then use these cached files each time the user loads the website.  It means it doesn’t have to make requests continuously, which reduces the load on the web server while retaining the user’s data!
• Most service workers support a standard format for checking whether the data in the cache is outdated. You could use this to send a notification to the user announcing the availability of a new version of the application.

Want to get to work yourself?

To close, I would like to stress my core message: planning to build a PWA? Then keep the application’s performance and loading time in mind. As we all know, first impressions matter most. So, make sure you invest time in reducing the application’s loading time so that it is not at the expense of that of the user.