compress assets with brotli as well as gzip

[mappu]

Hi,

Brotli is a new compression method that produces smaller files than gzip. It's well supported by browsers.

It should be possible to compress the webroot directory with both gzip and brotli; store both versions in the generated assets.go file; and serve the best version of the file if br is in the Accept-Encoding header.

The main C brotli encoder/decoder has a CGO wrapper here: https://github.com/google/brotli/tree/master/go

There is also a pure-Go version of the brotli encoder/decoder here https://github.com/andybalholm/brotli converted with c2go (read more)

Thanks

[dmitshur]

Thanks for posting this this feature request.

It should be possible to compress the webroot directory with both gzip and brotli; store both versions in the generated assets.go file; and serve the best version of the file if br is in the Accept-Encoding header.

Doing that has a trade-off of making the generated assets file roughly 2x larger.

As a result, it might be preferable to make it an option (generate gzip only, generate Brotli only, generate both, and maybe some other combinations).

This decision is worth thinking about more. I want to make sure there aren't some other unexpected implications when going from 1 compression algorithm to more than 1.

There is also a pure-Go version of the brotli encoder/decoder here https://github.com/andybalholm/brotli converted with c2go (read more)

Oh, I didn't know a pure Go Brotli encoder exists by now, thank you for sharing that! (I was only aware of a pure Go decoder at github.com/dsnet/compress/brotli.) /cc @dsnet

At this time, I don't expect to have the time to work on this soon.

[silverwind]

Ideally one would use Zopfli (or another gzip-compatible algorithm) to generate gzip-compatible data and Brotli to generate brotli. Overall output size will always be less than factor 2, I estimate maybe factor 1.6 when storing both encodings.

Having both encodings available would be ideal because the raw bytes could be directly used for HTTP-based transfer compression.

I agree it needs to be configurable (allow 0, 1 or 2 algorithms) and the raw bytes need to be accessible for all algorithms too.

[lunny]

The compress maybe as an interface so that external could implement themselves.

[silverwind]

96.6% of browsers today support brotli, so I'm of the opinion now that gzip is no longer needed for frontend asset delivery, and the primary compression method should be brotli. Any client in those 3.4% not supporting brotli that can just get uncompressed stream.