Brotli: A Rewarding Alternative to JSON Compression

A constant challenge for a website is to achieve the best possible visitor experience. As a CMS provider, we know that optimizing the size of files sent to the browser can dramatically shorten the time it takes for a page to load. Faster page load times lead to more and happier users, a lower bounce rate, and better Google rankings.

This article is about the advantages of Brotli compression for sending JavaScript and other assets to the browser, and how a website owner or DevOps team can make sure it is enabled for your AWS CloudFront distribution.

The path to Brotli

Always trying to optimize our website loading speed, we realized that one of the largest payloads of a page is the Scrivito content dump. This is a JavaScript file containing a big stringified JSON object. It is used for preloading all the CMS data required for initially rendering the page.

Wondering if the cost of the payload can be reduced, we have done some research on JSON compression. Very soon we stumbled upon statements like this one on Reddit, with a notable final response:

[QUESTION] Looking to compress JSON significantly. Any suggestions?

“Have you looked into brotli? You can get pretty good compression (generally better than gzip) at level 11”

Or, as one of the existing compression libraries, “brick.json”, states in its Readme file:


Transfer data from server to client, choose Google Brotli

You may already have heard of Brotli. Reading up, we found some more and some less relevant details:

  • It got its name after a Swiss German bread roll (Brötli), which explains why it may sound obscure and somewhat funny to a non-Swiss German.
  • Brotli was developed by Jyrki Alakuijala and Zoltán Szabadka. Both work at Google Research Europe in Zürich, and have a super-long track record of compression research in all directions. So, these guys definitely know their stuff.
  • What makes Brotli superior to other algorithms is the huge dictionary it comes with. It contains the most frequent words found in several natural and computer languages.

The state of Brotli today

Brotli got a lot of traction, as all major browsers added support for it in recent years, followed by large platform providers. Netlify, for example, made Brotli available to their customers. Also, AWS announced it last September, stating:

“Brotli is available for immediate use at no additional cost.”

As we are using AWS CloudFront for delivering assets to our and our customers’ websites, we wondered why they were transferred using the less modern gzip content type on some sites.

Is this specific asset served with Brotli (br) compression?

curl -o /dev/null -v \
-H "Accept-Encoding: deflate, gzip, br" 2>&1 | grep content-encoding

< content-encoding: gzip

Obviously not. We had scanned the settings in the AWS console, and they looked good. The default CloudFront policy has Brotli enabled. So, why didn’t it work out of the box?

We assumed that Brotli wasn't applied to CloudFront distributions created before AWS had added the new compression feature. But there was no definite hint in the docs.

At third glance, we discovered this little gem: An option, set to some magic legacy setting.

Setting up CloudFront

To get there in the AWS console:

  • Click on your CloudFront distribution,
  • select the “Behaviors” tab,
  • in the list, check the behaviour (in our case, there was only “Default”),
  • click the “Edit” button,
  • find the “Cache and origin request settings”.

Now, change “Use legacy cache settings” to “Use a cache policy and origin request policy” and confirm by clicking “Yes, Edit.

Because of CloudFront's conservative caching, it didn’t seem to make a difference at first. But every asset uploaded after this adjustment was in fact served with Brotli encoding!

< content-encoding: br

Two-digit savings

A two-digit percentage drop in bandwidth usage, with a negligible decompression overhead, for free! Merely by verifying and adjusting the settings.

If you aren’t sure if your assets are already compressed by Brotli, we highly recommend you to have a look!

Regarding the findings about JSON compression (in short):

Using Brotli compression is the proper approach to server-to-client communication.

Half of the existing JSON compression libraries would actually make the compressed payload bigger and also add a computational overhead to it.

Lessons learned

  • Turning the right screws can give you a big reward.
  • Measuring and analyzing beforehand keeps you from moving in the wrong direction.
  • Also, service provider announcements may really be worth reading.
  • Sometimes, simply enabling a new setting does the job.