[code-infra] Bundle size checker, report brotli size instead gzip

[oliviertassinari]

Summary

At one point, I would expect Brotli to carry most of the raw bandwidth of the internet. When this happens, it would make more sense to optimize the size for Brotli.

I guess https://caniuse.com/brotli is a driver in the growth of Brotli. But also, if the table in https://speedvitals.com/blog/zstd-vs-brotli-vs-gzip/#introduction is accurate, gzip won't go away; the web needs a fast compression algorithm for the first cache misses.

Current usage is hard to find, some source I don't think we can trust:

• https://www.wmtips.com/technologies/compression/
• https://w3techs.com/technologies/details/ce-compression

To also consider that the industry compares other libraries with third-party tools, once https://bundlejs.com/ or http://bundlephobia.com/ (pastelsky/bundlephobia#266) moves to show brotli by default, it would also be a signal for us.

Examples

No response

Motivation

No response

Search keywords: -

[Janpot]

At one point, I would expect Brotli to carry most of the raw bandwidth of the internet. When this happens, it would make more sense to optimize the size for Brotli.

For pre-compressed cdn-hosted content, which would likely be what our performance conscious users would be using to host bundles containing our libraries, I assume brotli would be the favoured algorithm. I think our choice of measurement should match this type of user.

To also consider that the industry compares other libraries with third-party tools

It's a good point in favor of continuing to optimize gzip size. It's a bit weird as these tools would be used by the aforementioned user segment to make informed decisions, but they wouldn't be using gzip in production. Do we optimize for their outcome, or for their decision making process?

Maybe we should start by reporting both, instead of either brotli or gzip?