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

21–30 of 109 posts

Re: What CSS minifiers also leave behind

#21

Post by pasta »

zuzun wrote: post #13
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…

> So minifying your stuff will only help you a little. True, the difference between 10KB compressed and 7KB minified+compressed is negligible for your visitors, but it still takes 30% off of your traffic bill.

This might be the only valid reason. But only for website that have a huge amount of traffic.

Re: What CSS minifiers also leave behind

#22

Post by xentronium »

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…

Man, just post a link to CV like you're advised and let good things happen to you. If they don't, you lose nothing, but if they do, you got something out of your effort.

Re: What CSS minifiers also leave behind

#23

Post by camus2 »

flukus wrote: post #11
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…

The other benefit is from combining files and reducing the number of http requests. Minifiers are really needed for that, but the do make for some nicer development workflows.

> The other benefit is from combining files and reducing the number of http requests. Minifiers are really needed for that, but the do make for some nicer development workflows.

debatable with HTTP2 . Furthermore, separate files are easier to cache. If one of them doesn't change it doesn't have to be loaded again. That's my experience with bundles, especially when one uses asynchronous module definition instead of babel, webpack and co.

Re: What CSS minifiers also leave behind

#24

Post by dottedmag »

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…

I have seen a script which was 250kb gzipped, but 125k minified+gzipped.

It was a script embedded to the other people's pages (and yes, it delivered substantial functionality, it was not just a tracker), so minification saved a lot of traffic/money for the company.

Re: What CSS minifiers also leave behind

#25

Post by merb »

_9vpl wrote: post #20
flukus wrote: post #11

Earlier quoted context omitted.

The other benefit is from combining files and reducing the number of http requests. Minifiers are really needed for that, but the do make for some nicer development workflows.

Number of HTTP requests is not a concern with HTTP2 server push and multiplexing. In fact it's usually better to have 2 fairly sized files that can be downloaded in parallel rather than 1 large file.

probably not true, since most http/2 implementations that I know of use time multiplexing, which means that only one element at a time can pass, so the time is exactly the same.

I mean if I split a file in 10 exact pieces or if I split two files in the exact same 10 pieces as well I still have the same data.

(Edit: Well basically two files have mostly more data since they both might contain a BOM or so)

Re: What CSS minifiers also leave behind

#26

Post by jwilk »

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.

Pro tip: you can increase your chances of getting hired by 4.2% by not saying Le Sigh.

Re: What CSS minifiers also leave behind

#27

Post by abritinthebay »

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.)

Really? It seems that CSSO was the strong winner.

It didn't possibly create bugs by rewriting to new units (especially poorly supported units like q) and had the best results overall.

I'd like it to be a wee bit more aggressive on the rounding but other than that it seemed a clear winner.

Re: What CSS minifiers also leave behind

#28

Post by Klathmon »

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…

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.

Re: What CSS minifiers also leave behind

#29

Post by mercer »

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't have a problem with the idea of having styling embedded in the final page.

What I'm curious about is if this has any kind of negative impact on performance, bandwidth, etc. Because the CSS is loaded on the component level, and because Webpack 2 does tree shaking, the page will be guaranteed to only contain CSS for the components that are on the page. And if I'd 'lazy-load' parts of the app, I'd get that benefit for my CSS as well with no extra effort.

On the other hand, any benefits of having a compiled (and hopefully cached) bundle.css are offset by the need for an extra request for the css file, as well as the very likely situation that there'll be a bunch of unused css in that bundle.

Am I missing some drawback to the above-mentioned approach?

Post reply on HN