How does Brotli compression differ from gzip compression?

Brotli uses a larger search window of up to 16 MB versus gzip's 32 KB, plus a built in dictionary and context modeling. These additions let it find more repeated patterns and encode them with fewer bits. The result is smaller files at similar decompression speed.

Why is Brotli better than gzip for Unity WebGL builds?

Unity WebGL builds are large single files where identical byte patterns appear far apart. Brotli's 16 MB window keeps those patterns in memory, while gzip forgets them after 32 KB. Tests show Brotli cuts empty scene build size by about 24 percent versus gzip.

Does Brotli work over plain HTTP or only HTTPS?

Browsers only accept Brotli encoded content when delivered over HTTPS connections. On plain HTTP they do not advertise support, so the server must fall back to another encoding. Local test servers without a certificate will not serve Brotli to browsers.

What Brotli quality level should I use for static web assets?

For files compressed once and served many times, such as WebGL builds or scripts, level 11 gives the best ratio. Levels 4 or 5 suit per request data like JSON because they balance CPU cost and size. The highest levels take much longer to compress but decompress at similar speed.

What Brotli is and why it beats gzip on the web

Q: How do I configure my server to serve Brotli compressed files?

The web server must send the header Content-Encoding: br for the precompressed .br files. Unity provides sample configurations for Apache, Nginx and IIS to set this correctly. Without the header the loader may fail or use a slower JavaScript decompressor.

Brotli is the compression format Google built to replace gzip on the web. It produces smaller files, decompresses just as fast, and every current browser supports it. For a Unity WebGL game it is the setting that gets your download size down the most. Let us have a look at how Brotli works, where it differs from gzip, and what the numbers look like. The comparison article that follows helps you decide which one to pick for a WebGL build.

A short history

Brotli was created by Jyrki Alakuijala and Zoltán Szabadka at Google in Zurich. The first version from 2013 was made for one job only: compressing web fonts in the WOFF2 format. In 2015 Google released a general purpose version, and in July 2016 it became an internet standard as RFC 7932. Chrome, Firefox and Edge added support in 2016 and 2017, Safari in version 11 (2017). According to Can I use, about 97 percent of global web traffic comes from browsers that accept it today. The name is Swiss German for a small bread roll.

How Brotli works

Brotli builds on the same two steps as gzip: find repeated byte sequences and replace them with back references, then encode everything with short bit codes. On top of that it adds three things.

A much bigger window

Gzip can only look back 32 KB for a repeat. Brotli can look back up to 16 MB. A Unity WebGL build is one big WebAssembly file plus one big data file, and in files like that the same byte patterns show up megabytes apart. When gzip has long forgotten them, Brotli still remembers.

A built-in dictionary

Brotli ships with a static dictionary of 13,504 common words and phrases, 122,784 bytes in total, baked into every encoder and decoder. It contains things like function, <div class=", Content-Type and many English words. When the compressor sees one of these in your data, it can reference the dictionary even if the phrase never appeared in the file before. On top of the 13,504 base words there are 121 transforms, for example "make the first letter upper case" or "add a space after it", so one entry can stand in for many spellings. The dictionary helps a lot for HTML, CSS and JavaScript. For a WebAssembly binary or a texture it helps very little, but the bigger window and the next feature still apply.

Context modeling

Gzip uses one Huffman table per block for all literal bytes. Brotli can switch between several tables depending on the previous one or two bytes. After a < in HTML, the next byte is probably a letter. After a byte of a float in a mesh, the next byte follows a different pattern. Picking the table based on context lets Brotli spend fewer bits on each byte, and this is where a lot of the extra savings on binary data come from.

Quality levels 0 to 11

Like gzip, Brotli has levels, but twelve of them. Levels 0 to 4 are quick and meant for compressing on the fly. Levels 5 to 9 search harder. Levels 10 and 11 do a very expensive extra pass and are meant for files you compress once and serve many times. Unity uses the top level for WebGL builds, which is why Brotli builds take noticeably longer than gzip builds.

The numbers

Here are results from Google's own 2015 study on the Canterbury corpus, a standard test set of 11 text and binary files. The ratio is original size divided by compressed size, so higher is better.

Algorithm	Compression ratio	Compression speed	Decompression speed
deflate (gzip) level 1	2.91	93.5 MB/s	323 MB/s
deflate (gzip) level 9	3.37	15.5 MB/s	347 MB/s
Brotli level 1	3.38	98.3 MB/s	334 MB/s
Brotli level 9	3.97	17.0 MB/s	355 MB/s
Brotli level 11	4.35	0.5 MB/s	290 MB/s

Two things stand out. Brotli level 1 compresses as well as gzip level 9 while running six times faster. Brotli level 11 compresses about 29 percent better than gzip level 9, but takes about 30 times longer to do it. Decompression speed is about the same everywhere. The lzbench 2.4 benchmark on the 211.9 MB Silesia corpus tells the same story on a modern CPU (one core of an AMD EPYC 9555P):

Algorithm	Compression speed	Decompression speed	Size vs. original
zlib (gzip) level 6	26.8 MB/s	314 MB/s	32.2%
zlib (gzip) level 9	11.3 MB/s	318 MB/s	31.9%
Brotli level 5	53.3 MB/s	419 MB/s	28.1%
Brotli level 8	12.6 MB/s	443 MB/s	27.0%
Brotli level 11	0.56 MB/s	383 MB/s	23.8%

Brotli at level 11 produces a file about 25 percent smaller than gzip at level 9, and still decompresses faster.

A real world case

LinkedIn measured what this means for a big JavaScript file from their site. Brotli level 11 made the file 30 percent smaller than gzip level 6. The compression time went from 169 ms to 11,913 ms, while decompression time dropped from 35 ms to 22 ms. After switching, their page load time at the 90th percentile improved by 2 to 3.6 percent in the US and 6 to 6.5 percent in India, where connections are slower. For a Unity WebGL build, a developer in a Unity forum thread posted an empty scene build in Unity 2021.2 at 2.9 MB with gzip and 2.2 MB with Brotli, about 24 percent smaller. The Brotli compression step in the build log took 51 seconds.

The catch

Browsers only accept Brotli over HTTPS. Over plain HTTP they do not even announce support. For a game on a web portal or your own domain with a certificate this is not an issue. For a local test server without HTTPS it is. The second catch is that your web server has to send the header Content-Encoding: br for the .br files Unity produces. If it does not, Unity's loader either fails or falls back to a slow JavaScript decompressor. Unity has sample configurations for Apache, Nginx and IIS.

Where to use Brotli

Brotli is the right pick for anything you compress once and download many times: your WebGL build, your web page, fonts and scripts. Use level 11 for those. For data your game server generates per request, like JSON state or leaderboards, use Brotli level 4 or 5. You get smaller output than gzip at about the same CPU cost. For assets loaded from local disk during play it is the wrong tool, in the same way gzip is. There you want LZ4, which we cover in its own article.

What Brotli is and why it beats gzip on the web

A short history