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.