Hacker News Reader

Comment by seu | Hacker News Reader

This is all great, but while the internet is filled with auto-playing videos and invokes to external scripts from google, meta, amazon and who knows where, the example on this page is about saving... 148 bytes? Does minifying CSS really make a big difference, in the end? I'm guessing that a page with a serious CSS payload (say, over 100k) already has more serious weight problem elsewhere.

View on HN

The main problem with CSS is that it is "render blocking". If you want the user to see stuff sooner you have to make the CSS smaller and/or serve it faster (e.g. inline it to avoid another request).

how sooner will I see the stuff if I use this tool?

I haven't measured yet but my guess would be that on current devices 99% of the CSS size saving matters for making the transfer of the CSS faster over the network (and that the speed up in constructing the CSS Object Model is negligible).

=> Users with low bandwidth and/or flakey connection benefit

Happy to learn otherwise though!

CSS is a high level language used very often as a low level one. The styling doesn't use any "cascading" and everything is repeated all the time. In this context minifying can make a difference. But either way it is not among my favorites.

Does minifying make any difference if you're gzip-ing it in-flight anyway?

Edit: I mean, in the real world. Obviously in their example gzip does pretty much nothing since there's so little content, which leave very little room for compression.

Recently tested compressing picocss, one version was 80k or something. gzipd to 16k, +min, 13k. Brotli 13k, +min 10k.

So maybe another thirty percent, probably from removing comments etc, not just whitespace.

Thanks.

CSS is text based, so it should be gzip (or brotli) compressed. Minifying something isn't as effective as compressing it. You could do both, but the difference is small.

The numbers above are already referring to the gzipped raw vs gzipped minified.

never mind a "big" difference, I would be surprised if it made a "measurable" difference

1. The README example is 54% reduction (for gzipped result).

2. CSS often blocks page render, to avoid flashing unstyled content.

3. "Tree-shaking" CSS is often difficult or impossible.

Many (most?) CSS libraries minify their outputs...Bootstrap, Materialize, Semantic UI, Foundation.

I started linking component stylesheets directly in the component HTML, de facto eliminating unused CSS from the output. HTTP3 provides performance gains we can benefit from by serving multiple CSS files "just-in-time".

I've had great results since. No more unused CSS. No more minifying nor bundling. What you write is what you get. It's liberating! Hehe.

That's good. Also, that doesn't work for a library where you're using one of six button styles.

Reply on news.ycombinator.com