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

31–40 of 109 posts

Re: What CSS minifiers also leave behind

#31

Post by snitko »

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'…

Embedding css into a webpage forces this css to be loaded every time. Even if the css only contains what's needed for the page, it can still be a lot. Caching it is just common sense. I think if you try and calculate, there will be a lot of bandwidth saved if you separate css into a file.

Re: What CSS minifiers also leave behind

#32

Post by dspillett »

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…

> 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 8KBytes and the maximum is 32KBytes. Even if you use the maximum at the expense of CPU time that isn't going to cover many large files. Minifying increases the effective range of the compression window, each match is shorter but you will find more matches and usually this balances out in a way that benefits the compression result.

It isn't quite that simple in reality as there is huffman encoding and other tricks in the mix. This means that even for inputs smaller than the compression window you may see some benefit as minifying can reduce the input data's alphabet significantly.

Ignoring the "why it helps", it is easy to show that it does help in a great many real cases:

  ds@s2:/tmp$ wget --quiet https://code.jquery.com/jquery-3.2.0.min.js
  ds@s2:/tmp$ wget --quiet https://code.jquery.com/jquery-3.2.0.js
  ds@s2:/tmp$ gzip jquery-3.2.0.min.js
  ds@s2:/tmp$ gzip jquery-3.2.0.js
  ds@s2:/tmp$ ls -l j*
  -rw-r--r-- 1 ds ds 79201 Mar 16 21:30 jquery-3.2.0.js.gz
  -rw-r--r-- 1 ds ds 30023 Mar 16 21:30 jquery-3.2.0.min.js.gz
In this example the result of min+comp is less than 40% the size of the result from compression alone.

For completeness, minifying alone achieves less than compression alone:

  -rw-r--r-- 1 ds ds 267686 Mar 16 21:30 jquery-3.2.0.js
  -rw-r--r-- 1 ds ds  79201 Mar 16 21:30 jquery-3.2.0.js.gz
  -rw-r--r-- 1 ds ds  86596 Mar 16 21:30 jquery-3.2.0.min.js
  -rw-r--r-- 1 ds ds  30023 Mar 16 21:30 jquery-3.2.0.min.js.gz
One further factor is CPU time consumed on the client decompressing and parsing the content but this is likely to be insignificant compared to the network or local IO time, if a device's CPU is under-powered enough that this is significant then it is unlikely to be able to run the decompressed code with useful performance.

Re: What CSS minifiers also leave behind

#34

Post by the8472 »

diamondo25 wrote: post #14
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?

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.

Re: What CSS minifiers also leave behind

#35

Post by mattmanser »

dspillett wrote: post #32
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…

> 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…

Are you sure that's not just comments being removed?

Re: What CSS minifiers also leave behind

#36

Post by replete »

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.

Re: What CSS minifiers also leave behind

#37

Post by ricardobeat »

dspillett wrote: post #32
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…

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

Re: What CSS minifiers also leave behind

#38

Post by ricardobeat »

snitko wrote: post #31
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'…

Embedding css into a webpage forces this css to be loaded every time. Even if the css only contains what's needed for the page, it can still be a lot. Caching it is just common sense. I think if you try and calculate, there will be a lot of bandwidth saved if you separate css into a file.

Not true. The CSS is inlined as strings in the js file, and benefits from caching just as much as the rest of your templates (this is for single-page apps).

Re: What CSS minifiers also leave behind

#39

Post by CapacitorSet »

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.

Re: What CSS minifiers also leave behind

#40

Post by phire »

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 think that there is merit in designing a minifier that is explicitly designed to optimise the gziped size rather than the uncompressed size.

Things like:

* Rearrange rules within the file to put similar rules within the sliding window.

* Rearrange rules so that tail of the last declaration of one rule and the start of the next selector create the longest possible common substring.

* Rearrange the order of declarations within the rules to maximize the length of common substrings that span two declarations, ie ": 2em;\nbackground-color: rgb("

Post reply on HN