Comparing Brotli and gzip

A few weeks ago, one of the Android developers on our team suggested that we could use Brotli to improve performance on our Web and mobile clients. I had never heard the name before, so I took a look: Brotli is a compression format originally developed at Google with an open-source implementation. It’s supported by the major browsers (see Can I use Brotli?), so it can replace gzip for Web traffic.

However, before we enable it, we wanted to make sure it performs better than gzip.

There are several articles on the Web comparing the two, but they all seem to get their numbers from this 2016 blog post: Understanding Brotli’s Potential. It compares compression ratios for HTML, CSS, and JavaScript and concludes that Brotli has both better compression ratios and higher compression speed. Sounds good, but I wasn’t totally convinced this was relevant for us – what matters most in our case is compressing the JSON responses from our API, and to make an informed decision it would be better to see the comparison for that data.

After taking a look at the Brotli website, I realized it would be pretty easy to write my own little comparison tool in Go. The Brotli library is written in C, but it has good Go bindings and the Go standard library includes a gzip implementation. I could also use Go’s tooling for benchmarks to measure compression and decompression speed.

The tool

The comparison tool is now available at github.com/fromAtoB/compression-comparison. It uses a file in the source folder as input for the comparison; you replace the file with your own data to get the results most relevant for you.

Results

In our case, the most important data to compress is the response of the “search” endpoint. This contains a list of flight/train/bus/carpooling connections, and it’s what users are waiting for when they look for a connection on our apps or website. I saved the response from a search request to a file and ran the comparison tool.

Here are the results (the Brotli column is with the quality parameter set to 4):

                            gzip    Brotli     Change
Size (bytes)               14435     13254     -8.2 %
Compression time (ms)      1.584     0.675    -57.4 %
Decompression time (ms)    0.087     0.104    +18.9 %

As we’d hoped, Brotli does a better job compressing our data. 8.2 percent is not massive, but it’s significant.

However, the increased decompression time might be a problem. If the client is a phone or tablet, it’ll have slower hardware than the server, so the decompression time matters more. To get a rough estimate, let’s assume the client is 10 times slower than the server. We can just multiply the decompression times, giving 1.584 + 10 * 0.087 = 2.454 ms for gzip and 0.675 + 10 * 0.104 = 1.715 ms for Brotli. So Brotli still comes out ahead.

Doing your own comparison

If you’re considering Brotli and want to see how it performs on your data, follow the instructions in the README.

The comparison tool also prints numbers for Brotli with quality 11. With our sample data, this increased compression times by 141 times compared to gzip, so I didn’t even include it in the results. But if you’re thinking of setting it up for static content, it might still be an option.

Join the team

View open positions