Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What CSS minifiers also leave behind

luisant.ca

Post reply on HN
Print view View original

71–80 of 109 posts

Re: What CSS minifiers also leave behind

#71

Post by rictic »

billyhoffman wrote: post #45
Klathmon wrote: post #28

Earlier quoted context omitted.

One massive thing minifying does is dead code elimination (slightly less applicable to CSS but it still applies using some build stacks) We can build a "prod" version of the app and the minifying process will drop all the debugging code as well as any unused or uncalled functions from the output.

What JS Minifier do you know that does dead code elimination? I would have thought that understanding what functions of a dynamic language that can be safely removed would require parsing/AST analysis beyond those found in the typical minifier.

Closure compiler, while trickier to use than the other options, will do dead code elimination, constant propagation, and other classic whole-program optimizations.

Re: What CSS minifiers also leave behind

#72

Post by bastawhiz »

replete wrote: post #36

Don't mean to squash any enthusiasm, but these types of 1byte optimization savings don't really have real-world benefits due to over-the-wire compression like gzip and Brotli. A more interesting problem to solve, I think, is that of optimising CSS rules for browser rendering.

One of the main reasons these optimizations happen is actually to make compression better. If you have a mix of px/pt/cm/mm in your stylesheet, it's more than likely that making them consistent (in their smallest possible form) makes them more uniform, making them more compressible.

I used to have a doc with actual numbers, but I've since lost it. If I dig it up, I'll link it here.

Re: What CSS minifiers also leave behind

#73

Post by bastawhiz »

tambourine_man wrote: post #46

Didn't know about all of those units. q, mm, cm… scientific notation?! Also didn't know one could use counters already. Browser support is great. I thought it was still under approval. Amazing stuff, thanks

CSS is a far bigger spec than anyone knows. Did you know that you can put dots and spaces in your CSS classnames? Bonus points if you can figure out how to escape characters in CSS identifiers ;)

Re: What CSS minifiers also leave behind

#74

Post by bastawhiz »

WorldMaker wrote: post #69
mercer wrote: post #29

I have a slightly-related question for those of you familiar with Webpack, css modules (css-loader/style-loader), and perhaps React as well: is there any reason not to use the 'default' approach where the styles for the components are simply inserted in a (with unique, generated classnames)? To be clear: I don't mean philosophical reasons. I personally love letting javascript deal with the 'cascading' part and I don'…

tags in the middle of the DOM often have a rerendering penalty (most browsers force an entire page rerender each time they encounter one). In a past life a website I worked on had a huge browser paint performance and content flash issue that was eventually cleared out by moving all the styles out of tags in the DOM.

Most webpack loaders put them in the

Re: What CSS minifiers also leave behind

#75

Post by bastawhiz »

mercer wrote: post #29

I have a slightly-related question for those of you familiar with Webpack, css modules (css-loader/style-loader), and perhaps React as well: is there any reason not to use the 'default' approach where the styles for the components are simply inserted in a (with unique, generated classnames)? To be clear: I don't mean philosophical reasons. I personally love letting javascript deal with the 'cascading' part and I don'…

When you're using a loader, the CSS still exists, it's just a big string in your JS bundle. By default, I believe css-loader/style-loader will use cssnano to minify the CSS within your bundle.

What will be very interesting in the coming years (as the work gets done around it) is "full css" optimization. That is, when you know you have all of the styles for the whole page available to the minifier. If the minifier knows that no other CSS is being loaded, it can do a lot more work to remove and merge rulesets. In the case of styles bundled with Webpack, common CSS could be reduced even further, after tree shaking has taken place.

Re: What CSS minifiers also leave behind

#76

Post by bastawhiz »

fleetfox wrote: post #12

Can someone provide some hard numbers from real projects as to is it really worth it assuming we can gzip/brotili?

If you have a build step (you probably do), in most cases it's as simple as running `npm install --save` for your minifier of choice and adding one line to your build script.

Even if the difference is minimal, it could mean the difference between, say, three TCP packets and four, which adds up for users on high-latency connections.

Re: What CSS minifiers also leave behind

#77

Post by bastawhiz »

WhitneyLand wrote: post #47

Are there any good tools for deobfuscating css/js if you want to study a technique used on some web page?

If you're using Crass, it has a --pretty flag that will pretty-print your CSS, even after minification. You can play with it online here, too:

http://www.mattbasta.com/crass/

Re: What CSS minifiers also leave behind

#78

Post by bastawhiz »

cfqycwz wrote: post #59
Silhouette wrote: post #33

Here's the same author's earlier post on this subject, "The missed chances: What minifiers leave behind", from last week: https://luisant.ca/css-opts-survey

Anybody know if the transparency one is actually a desirable optimization? Iirc, you might want to assign a color to your transparency so it's not shifting hue as you fade it in through CSS transitions, animations, or JS.

Author of crass here. That's interesting: if you have a specific case where the browser doesn't do what you'd expect, I'd love to see it in a Github issue!

https://github.com/mattbasta/crass/issues/new

Re: What CSS minifiers also leave behind

#79

Post by WorldMaker »

bastawhiz wrote: post #74
WorldMaker wrote: post #69

Earlier quoted context omitted.

tags in the middle of the DOM often have a rerendering penalty (most browsers force an entire page rerender each time they encounter one). In a past life a website I worked on had a huge browser paint performance and content flash issue that was eventually cleared out by moving all the styles out of tags in the DOM.

Most webpack loaders put them in the

Fair point. Once packed into the is better.

There's still a care to be taken when using tags in development. I know developers don't always respect development performance (because it's just development), but that performance can still matter: to you in your debug cycle time, and also sometimes bad performance in development masks bad performance that will impact production (and developers don't notice it because it "always performs that way when I test").

For that reason, bringing the aside somewhat back on topic, I often prefer to use minified stylesheets/JS in development and trust sourcemaps to do their job when I need to debug them.

Re: What CSS minifiers also leave behind

#80

Post by iainmerrick »

Klathmon wrote: post #43
ricardobeat wrote: post #37

Earlier quoted context omitted.

Most of the gains in there are from stripping out comments. That plus whitespace removal gets you most of the benefit. I don't think the parent was advocating for dropping minification completely, but investing massive effort when you're already at the crest of the curve.

It's not like this is a zero sum game. Attempts at improvement don't hurt at all, and in some cases can help a ton.

But they can hurt sometimes -- not all optimizations are always safe.
Post reply on HN