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

61–70 of 109 posts

Re: What CSS minifiers also leave behind

#61

Post by greenshackle2 »

remy_luisant wrote: post #5
cperciva wrote: post #2

I'm for hire now. Le Sigh. Email's in the footer. Remy: I'd suggest posting a CV and linking to it from this post. I looked and couldn't find one anywhere on your site; you'll get a lot more qualified interest if people can find out more about you than just a few blog posts.

I thought about it, but I'm way too shy for that. Not like it would lead to anywhere either, you know. :P Two years of teaching university, MSc in computing, love of automation, combinatiorial optimization without any significant amount of deep math skill, circuit design, gate array stuff, low-level CPU optimization stuff, hardware counters, microcontrollers, SQLite, Julia language, C, shell, a bunch more programming…

You're being silly, I'm a self-taught Python coder with a degree in agricultural engineering, a sprinkling of C, Linux, Lisp and statistics, almost no JavaScript, I'm headstrong and I dress like shit, and I still managed to find interesting opportunities in the job posting threads here.

Just post your damn CV.

Re: What CSS minifiers also leave behind

#62

Post by 52-6F-62 »

CapacitorSet wrote: post #39
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.

I partly agree. Though removing one or two bytes more than another minifier doesn't really matter that much, what matters is being able to deduplicate CSS as well as doing the usual whitespace elimination. SASS and SCSS seem to have a bit of a problem with duplicated CSS.

It's funny you should say that. I'm curious, do you have an example?

I'm engaging in this ugly probably unsightly (but helpfully quick and maintainable) practice in a project with a short developmental cycle right now, and I've yet to have any issues outside of temporarily forgetting that I have already globally defined a specific style or enclosed a style I thought I'd left global.

(It's a corp. annual report -- that my team got tasked with as a favour -- so it has some repeating styles, and others isolated between pages)

Re: What CSS minifiers also leave behind

#63

Post by bigbugbag »

pasta wrote: post #8

This looks like a fun project indeed! Unfortunately every time I read something about minifiers I got the feeling that people are optimizing the wrong problem. If you gzip data over the line it's already compressed. So minifying your stuff will only help you a little. The problem is on the client side. You can compress what you like but if the browser starts dropping frames because it has to compile/handle a ton of J…

Gzip compression over https is a vulnerabilty[1].

Depending on the scale, shaving a few kB here and there can amount to significant savings in the long run.

[1]: https://en.wikipedia.org/wiki/BREACH

Re: What CSS minifiers also leave behind

#64

Post by diamondo25 »

the8472 wrote: post #34
diamondo25 wrote: post #14

Earlier quoted context omitted.

Don't forget that gzip/brotli only affects the shipping time. This would be the process: 1. Server: check Accept-encoding header for gzip or brotili support 2. Server: compress either brotli or gzipped file, or fall back to a raw file 3. Server: send data to client 4. Client: receive (and decompress, if not raw) 5. Client: parse (big) resource Also, compression through uglifying/minifying improves parse speed, which…

> 2. compress No, you don't need to waste CPU cycles on compression for each connection. You can store the .css.gz on the filesystem along with the .css and have the webserver pick up the appropriate file based on Accept-encoding. That way you can precompress with the slowest compression options.

Of course, there are multiple ways to optimize it (like storing stuff at a CDN), but I'm pretty sure 95% of the people do not precompress their assets.

Re: What CSS minifiers also leave behind

#66

Post by diamondo25 »

ricardobeat wrote: post #37
dspillett wrote: post #32

Earlier quoted context omitted.

> If you gzip data over the line it's already compressed. So minifying your stuff will only help you a little. For small files you might be mostly correct, but for larger ones min+compress can product much better gains than compression alone. IIRC the algorithm used employs a rolling compression window, and can only match strings of tokens whose distance apart is smaller than that window. IIRC the default window is 8…

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.

Stripping out comments would be one, but eventually remove all useless code and optimizing it using tools like Google Closure Compiler is way more effective in most websites that use a single bundle for everything.

Re: What CSS minifiers also leave behind

#67

Post by ricardobeat »

diamondo25 wrote: post #66
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.

Stripping out comments would be one, but eventually remove all useless code and optimizing it using tools like Google Closure Compiler is way more effective in most websites that use a single bundle for everything.

When the subject is CSS, dead code removal is a way more complex problem, and only possible if your usage falls within certain constraints. Best bet is a component system with scopes styles that ensures you are only loading what is required.

Re: What CSS minifiers also leave behind

#68

Post by WorldMaker »

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.

Rollup (and relatives) even do tree shaking if you use ES2015 Modules. (Those modules have a static-analysis friendly set of requirements.)

Re: What CSS minifiers also leave behind

#69

Post by WorldMaker »

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.

Re: What CSS minifiers also leave behind

#70

Post by bastawhiz »

ovao wrote: post #6

crass is doing some really wonderful stuff here -- I'm impressed! It's very interesting, however, that no one minifier is a consistent winner in these test cases, and that running CSS through multiple minifiers is actually, potentially, not all that crazy. (The very debatable real value in doing that notwithstanding.)

I appreciate the compliment! (author of crass here)

I've mentioned it before, but it's really not a great idea to use multiple minifiers. Minifier bugs can get nasty, and using multiple minifiers exponentially increases the likelihood that you'll encounter some weird or broken behavior. Make sure to test thoroughly.

Post reply on HN