Photo by Brett Jordan on Unsplash

Using Brotli with Preact — CLI 3

Preact CLI is a PWA/SPA scaffolding tool which uses tools from Preact Ecosystem to build the same.

If you’ve ever done any web performance tasks of any web content or looked at any performance report from any tool than you would know that most content sent over wire is compressed before sending it to the browser. As of now most of this is done in the form of GZip compression.

As a web developer you build your web app using any tool/framework etc and upload to any hosting provider. After this, these web servers upon receiving a request for any asset compress the response using GZip and send it to the client who decompresses it using the algorithm mentioned in content-encoding response header.

A similar but latest algorithm in this space is Brotli compression algorithm. It has shown to improve compression ratios for web content and is a successor of gzip and zopfli algorithms.

This new format allows us to get 20–26% higher compression ratios over Zopfli. In our study ‘Comparison of Brotli, Deflate, Zopfli, LZMA, LZHAM and Bzip2 Compression Algorithms’ we show that Brotli is roughly as fast as zlib’s Deflate implementation. At the same time, it compresses slightly more densely than LZMA and bzip2 . — Google’s Official Blog

A better compression means less bytes to download for users resulting in faster download times and earlier time to interactivity and other metrics.

Important: However there are lesser bytes to download please remember that after decompression it is still same amount of code and thus resulting in same parse and eval time of the script.

Sadly, the support for the same is not really great from a lot of service providers. If you upload your web app without any changes major CDNs and hosting providers still use GZip out of the box with no support for Brotli at all.

Thanks to Service workers we have a good control to what resources we request from the network and switch what was originally requested by the browser.

In Preact-CLI we have a flag --brotli which automatically generates brotli compressed assets for all the javascript files. This means that all the generated javascript files also have a .js.br files next to them. These files are never requested by your web app on its own.

preact build --brotli

But the service worker installed by the scripts with type=module can be sure that they also support brotli compression. Check the following two links to be sure

https://caniuse.com/#feat=brotli

https://caniuse.com/#feat=es6-module

Without this flag

How a normal request response would work

With this flag

A request with this service worker in between is intercepted and converted to a `.js.br` file request

This service worker precaches the first party javaScript by precaching .js.br files. Whenever a page requests a first party .js file, service worker responds with the contents of corresponding brotli file.

Note: The decompression of the content happens before the contents are handed over to the service worker. Thus you have to make sure that all .br files are served with correct headers of content-encoding: br.

Most services allow you to do this by some or other config files.

• Netlify has _headers file where you can specify this custom header. https://www.netlify.com/docs/headers-and-basic-auth/

With these custom headers and the service worker precaching of Preact CLI you’re all set to take the benefit of Brotli compression without waiting for your provider to enable the same.

One such demo app is deployed at https://material-cli.netlify.com/. When you launch the app you will observe that all the precached files requested by the service worker are actually brotli compressed javascript files.

Before and After enabling Brotli compression in preact-cli.

We’re keen to hear feedback/issues and anything you wanna say on our github issues page.

Cheers.