GZIP compression — Server response optimizations

As a backend developer, I feel very passionate about performance and optimizations.
This is why I was very excited about learning about a simple way to decrease the download time and bandwidth required for the server response.

gzip is a file format used for file compression and decompression. It is based on the Deflate algorithm that allows files to be made smaller in size which allows for faster network transfers

Using GZIP compression will reduce your client’s download response size. It is essential with mobile clients.
Mobile network is limited by your mobile plan and usually much slower than the alternatives (wifi, ethernet, etc.)
For those, the reduced response size can dramatically improve your users experience and should not be taken lightly.

When not to use GZIP compression?

1. Small-sized responses — if the response is already quite small, then the compression will be negligible, and as compression takes CPU and memory, it will not be worth it.
2. Compressed data — Some files, such as PDF and JPEG, are already compressed and once again, the compression will be negligible and not worth it.

“Sounds great, too much work, won’t do it” — NO, it is minimal effort!

You might think compression/decompression on the client and server side will be a pain to write and maintain, but in reality, it is very easy as many libraries/frameworks assist with it.

Server-side:

For those who use the Springboot framework, it is easy as adding a single property!

server.compression.enabled=true //Enable the response gzip compression (Default: false)

//Additional properties to control the behaviour (wrote below the default values)
server.compression.mime-types=text/html, text/xml, text/plain, text/css, text/javascript, application/javascript, application/json, application/xml //List of supported mime types
server.compression.min-response-size= 2KB//Minimal response size to compress

If you don't use a framework that supports it out of the box, you need to GZIP it yourself and add a Content-Encoding response header. (still minimal effort)

You can easily verify it is working by sending a request with postman / curl (using curl -I)and see if you get “content-encoding: gzip” header.

Client-side:

You need to do nothing if your client code runs in a browser.
Yes. Nothing. All modern browsers support Content-Encoding header and will decode it for you.

If you don't get it out of the box for some reason, you can use the Content-Encoding header to understand if the response is compressed and decompress it using one of the many libraries that exist for it.

Final words
Although I have chosen to focus on GZIP file format, there are multiple supported compression types. Furthermore, you can use multiple compressions!
You can read about content negotiation to understand better how it works.

This post is the first in a series of blog posts I will publish that I like to refer to as ‘Tiny bytes’
Each blog post will be short and focus on a small interesting and practical topic.

Stay tuned for further tiny bytes posts!

Additional info about compression alternative:

So without further duo — Brotli!
Brotli is an alternative compression algorithm developed by Google. Using it you can achieve a smaller size response than GZIP.
So should we always use Broli? No, although you achieve a smaller response it takes a longer time to compress.
Choosing which one to use depends on your use case. I would pick GZIP for speed on not-too-large responses, and in case you want to achieve better size reduction pick Brotli.