Here's a comparison using `brotli --best` on my app.

   53K _long.css
   38K _short.css

   11K _long.css.br
  8.9K _short.css.br

Both, dev and prod, have hashes because that's part of what CSS Modules uses to avoid collisions.

Besides download size, smaller names improve parsing speed too.

You could also drop the hash part and gain most of that improvement. Or module and hash and do better on compression (because the hash is high-entropy).

Rudimentary experiment on https://github.githubassets.com/assets/te.1288ac5c9584fbf2.m... on replacing /(?<module>[A-Za-z0-9_-]+)__(?<local>[A-Za-z0-9_-]+)__(?<hash>[A-Za-z0-9_]{5})\b/:

${module}__${local}__${hash} (original): 72967 raw, 10993 br.

${module}__${local}: 68459 raw, 8867 br.

${hash}: 48754 raw, 8189 br.

${local}: 52610 raw, 7927 br. (Now in practice a few of these are likely to need disambiguation, so it’s probably a tad smaller than realistic.)

Frankly I think ${local} is the right target, with global disambiguation where necessary. For typical systems, I consider the hash approach to be foolish: its value is when interacting with unknown other styles, but when you’re compiling everything you should know everything, so you can disambiguate more selectively and succinctly/compressibly, as JS build tools like Rollup do (in flattening modules with colliding names, you’ll get Foo, Foo$1, Foo$2, &c.).

Personally I don't think this reduction in size is big enough compared to making all css names unreadable and thus very difficult to debug.

It also makes it much more difficult to create personal browser extensions as all css names are now unreadable.

This.

The only thing hashing classes achieves is making it difficult for users to use ad blockers and/or custom CSS. I understand why e.g. Meta does it on their sites, but for GitHub it makes no sense.