In this article, we will discuss how and why it is important to minify assets upon deployment before serving them across Gzip and Brotli.
It is important to note that we will only discuss the areas around “minifying” files and compression with Gzip and Brotli on the basis of sending them from a web server to a client browser.
What is Minification?
In recent years, the term “minification” has been used to describe the process of reducing the file size of JavaScript and Cascading Style Sheets (CSS) as much as possible without compromising functionality.
For example, the following JavaScript function could be reduced from:
function printName(name) {
// Prints a String to the console.
console.log(name);
}To this much shorter version:
function a(b)Expressive code is more easily read and understood by the developer. In the first example, there are 86 characters to transmit, and in the second, there is only 29. Understanding what function a has however, is less immediately obvious than printName.
Expressive code can be advantageous during the stages of development and testing. Minification therefore should be delayed until the code is deemed suitable for deployment on the production environment.
While the browser may use the minified code for the user, beautified code can be viewed in the developer toolbar to help with debugging in production by using source map files. These files are only downloaded if the source maps are enabled and the dev toolbar is open.
What is the Best Way to Minify Assets?
Web application frameworks can include minification modules to statically generate files.
This however, will depend on the programming language used:
- JavaScript frameworks may use Gulp
- Ruby on Rails may use Uglify (a wrapper for UglifyJS) (default)
- PHP frameworks may use Composer
Content delivery networks can also offer this service, and Cloudflare has become a one-stop solution for minification and compression with Gzip and Brotli compatibility.
What is Compression?
Compression is a process that reduces duplication in a dataset, usually having the desirable effect of reducing the size of the dataset. This is done by detecting repeated patterns and replacing them with more efficient encodings, as with run-length encoding, or with references to table of these patterns, as with LZ77-based DEFLATE algorithm used by GZip.
The reverse of this process is called decompression. Decompression is used to reproduce or approximate the original dataset.
After compression, less bytes are required to store and transmit the dataset.
Compressors often have a level which can be adjusted to trade compression or decompression time for greater reductions in size.
Changes to a dataset may be reflected in the internal data structures used during compression and maintained in the output. When these changes result in smaller internal data structures or more detectable patterns this leads to greater compression.
What Assets Should be Compressed?
Cloudflare can return both Gzip or Brotli encoded responses for many different types of files including:
- HTML
- CSS
- JavaScript
- JSON
- XML
- Plain Text
- Font Files
A full list of compression files can be found here.
Cloudflare will only auto minify resources which don’t use a .min.xx file format, to avoid accidental double compression. (Double compression is bad).
Gzip Compression
The Gzip compression level ranges between 1-10, with one being the fastest and largest, and 10 being the slowest and smallest file size.
A research piece by Jarrod on Root Users shows Gzip as a benchmark against other compression types. His research suggests that Gzip level 6 is a good trade-off between compression/decompression size and time.
Brotli Compression
Like Gzip, Brotli compression level starts at level 1, although it can go as far as 11.
In this research piece, written by Sam Saffron, we see the comparison between different Brotli compression levels.
His research concludes that Brotli at level 5 is competitive with Gzip, and that it starts using context modelling at this level, which is an advanced feature of the format.
Starting the Benchmarks
Before we begin, there are specific prerequisites for benchmarking a bash script called multitime. It’s available on Github to download (or build a binary yourself).
We took the beautified.js file and ran it through UglifyJS, which would be a one-off cost for each server deployment.
Now that we have these files, we can compress them both using Gzip level 6 (recommended) and Brotli level 11 (default).
| Normal | Gzip | Brotli | |
| Beautified.js | 733k | 180k | 147k |
| Minified.js | 283k | 84k | 73k |
- Gzip saves 75.4% and Brotli saves 79.9% from Beautified.js.
- Gzip saves 70.3% and Brotli saves 74.2% from Minified.js .
- Gzip saves 88.5% and Brotli saves 90.0% when starting from Beautified.js, minifying it and compressing respectively.
This overall file size saving reduces the file transfer size from the server to the browser.
From the above table, it is evident there are considerable savings, but we also need to understand the computational cost.
This computational saving is important for server stacks that could have to handle hundreds of thousands of people on a website at any given time.
Dynamic Compression
Both Gzip and Brotli offer dynamic compression, and the following modules are used to compress Gzip:
- Nginx uses ngx_http_gzip_module
- Apache uses deflate_module modules/mod_deflate.so
To understand how much time is required to compress the files, we ran a benchmark test for compressing our JavaScript file. For this, we used multitime to wrap the Postfix time before reporting back.
The following command runs the script 100 times with a confidence level of 95%. Here, we are mainly interested in the average (median) time, as environmental fluctuations can occur (shown with the standard deviation).
GZIP
multitime -n 100 -c 95 gzip -kf -6 beautified.js| Mean | Std.Dev | Min | Median | Max | |
| real | 0.037+/-0.0007 | 0.004 | 0.031 | 0.036 | 0.047 |
| user | 0.031+/-0.0004 | 0.002 | 0.028 | 0.031 | 0.039 |
| sys | 0.004+/-0.0003 | 0.001 | 0.002 | 0.004 | 0.009 |
multitime -n 100 -c 95 gzip -kf -6 minified.js| Mean | Std.Dev | Min | Median | Max | |
| real | 0.016+/-0.0004 | 0.002 | 0.013 | 0.017 | 0.021 |
| user | 0.013+/-0.0002 | 0.001 | 0.011 | 0.013 | 0.015 |
| sys | 0.003+/-0.0001 | 0.000 | 0.002 | 0.003 | 0.005 |
The beautified file took 36 milliseconds, while the minified file took 17 milliseconds.
Brotli
multitime -n 100 -c 95 brotli -kf beautified.js| Mean | Std.Dev | Min | Median | Max | |
| real | 1.761+/-0.0383 | 0.195 | 1.567 | 1.699 | 2.626 |
| user | 1.710+/-0.0275 | 0.140 | 1.549 | 1.665 | 2.183 |
| sys | 0.029+/-0.0030 | 0.015 | 0.013 | 0.024 | 0.084 |
multitime -n 100 -c 95 brotli -kf minified.js| Mean | Std.Dev | Min | Median | Max | |
| real | 0.681+/-0.0118 | 0.060 | 0.618 | 0.653 | 0.882 |
| user | 0.658+/-0.0098 | 0.050 | 0.604 | 0.635 | 0.822 |
| sys | 0.017+/-0.0014 | 0.007 | 0.009 | 0.014 | 0.036 |
Compressing with Brotli takes a considerable amount of time to compress in comparison to Gzip. The beautified file takes 1,699 milliseconds while the minified file takes 653 milliseconds.
Introducing Static Compression
Web servers can use a statically generated version of an asset. The initial cost is that the server will need to compress all files beforehand. This means a one-off cost can be used to create the compressed version of the asset, which is then served.
The server simply adds the standard file extension to file the compressed version. Gzip is “.gz” and Brotli is “.br”
Here are some installation guides for both Gzip and Brotli:
- Installing Gzip (Static) with Nginx
- Installing Brotli with Nginx
- Installing Gzip with Apache
- Installing Brotli with Apache
These web servers check the VARY HTTP header and route the request to either the static .gz version or .br version according to the request made.
How Much Does it Cost to Decompress?
Once the files have been compressed and sent across the Internet to the web browser, the next step is for the browser to decompress the file.
GZip Results
Decompressing the beautified.js.gz file:
multitime -n 100 -c 95 gzip -dkf beautified.js.gz| Mean | Std.Dev | Min | Median | Max | |
| real | 0.009+/-0.0003 | 0.002 | 0.007 | 0.009 | 0.013 |
| user | 0.004+/-0.0001 | 0.001 | 0.004 | 0.005 | 0.005 |
| sys | 0.003+/-0.0001 | 0.001 | 0.002 | 0.003 | 0.005 |
Decompressing the minified.js.gz:
multitime -n 100 -c 95 gzip -dkf minified.js.gz| Mean | Std.Dev | Min | Median | Max | |
| real | 0.008+/-0.0005 | 0.002 | 0.005 | 0.007 | 0.019 |
| user | 0.003+/-0.0001 | 0.001 | 0.002 | 0.003 | 0.006 |
| sys | 0.003+/-0.0003 | 0.001 | 0.002 | 0.003 | 0.009 |
Brotli Results
Decompressing the beautified Brotli file:
multitime -n 100 -c 95 brotli -kdf beautified.js.br| Mean | Std.Dev | Min | Median | Max | |
| real | 0.009+/-0.0004 | 0.002 | 0.006 | 0.009 | 0.015 |
| user | 0.003+/-0.0001 | 0.001 | 0.002 | 0.003 | 0.006 |
| sys | 0.003+/-0.0002 | 0.001 | 0.002 | 0.003 | 0.006 |
Summary
| Normal | Gzip | Brotli | |
| Beautified.js | 733k | 180k | 147k |
| Minified.js | 283k | 84k | 73k |
Our tests have consistently shown that minification leads to more efficient compression. Static compression is preferable over dynamic compression. We can also conclude that Brotli results in the smallest file at the end of the process, but both should be enabled in case the browser not being able to support one or the other.
