Switch to Brotli from Gzip

[JohnnyFangJr]

• Add a column for Brotli. I think it has wide-enough usage for static assets that it should be listed.
• Use max compression level for Gzip. Static assets are "pay once to compress", so there's no downside to max compression level.

[privatenumber]

Thanks for the PR @JohnnyFangJr! Those are great contributions.

Happy to accept the Gzip max compression level change if you don't mind pulling that out into a separate PR.

I'm not sure about displaying both Gzip and Brotli because it doesn't fit the page width and it adds more complexity to reading the table. The data should also be less about comparing compression algorithms, and more about showing how compressible the minified output is so I think just showing one of them is enough.

I'm currently leaning towards replacing Gzip with Brotli because that's what the standard is today. Sadly major services like Fastly (used by GitHub for example) don't even support Brotli yet, so I'm worried this will make the data less relevant/practical.

Do you have any data on the adoption of Brotli vs Gzip? I couldn't find any from a quick Google, but that might make this decision easier.

[JohnnyFangJr]

Fastly doesn't "do the work for you" where you can upload the uncompressed assets and they'll create the GZip version for you, but enable one to do it manually on their own.
All modern browsers from past several years support Brotli, CanIUse puts it at 94% availability browser-side.

But I'm guessing your question is about bottom-line real world usage.
I googled and only found this source claiming 33% adoption by the top 10 million websites.

I agree about having more than one compression algorithm being bad - the whole table becomes noisy. Whereas the existing one is crisp clean and concise.
I thought it would be nice to have Brotli as it's slowly becoming the de-facto standard, but maybe it's still too early.
Up to you :)

I'll separate using max compression into a different PR.

[privatenumber]

Thanks for sharing that link! Very useful, and seems recent too.

It's been a few days now but let me know if you're still planning to separate out the Gzip max compression to a separate branch.

Afterwards, this branch can be updated to replace Gzip with Brotli and I can build it to keep a reference.

[JohnnyFangJr]

I updated this branch along with the title so you'll have it for future reference.
Using max compression submit separately.

[privatenumber]

Thanks so much @JohnnyFangJr ! 🙌

[SukkaW]

• Use max compression level for Gzip. Static assets are "pay once to compress", so there's no downside to max compression level.

Both Cloudflare and Fastly don't provide information on which gzip compression level they are using.

Cloudflare uses level 5 Brotli compression (see https://blog.cloudflare.com/brotli-compression-using-a-reduced-dictionary/).

Terraform for Fastly VCL uses gzip level 3 as its default value (see https://registry.terraform.io/providers/fastly/fastly/latest/docs/resources/service_vcl)

Fastly also provide a Chrome extension chrome-extension-estimate-compression-level. If you test the extension on GitHub Pages (which is using Fastly), the estimate gzip level is 5.

So IMHO, we should set the compression level close to the real-world configuration (which should be 5), not the max.

[SArpnt]

at the very least i feel like the compression level should be stated

also the cloudflare and fastly compression level could probably be figured out by comparing local compression levels to whatever they're doing

[KuSh]

If I can add grist to the mill, here are the levels choosed by deno:

• Brotli: Quality level 6 is based on google's nginx default value for on-the-fly compression
• Gzip: After level 1, it doesn't produce significant size difference. Probably the reason why nginx's default gzip compression level is 1.