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

11–20 of 109 posts

Re: What CSS minifiers also leave behind

#11

Post by flukus »

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.

Re: What CSS minifiers also leave behind

#13

Post by zuzun »

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.

Re: What CSS minifiers also leave behind

#14

Post by diamondo25 »

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 is really helpful on (old) mobile devices. Adding compression through gzip or brotli introduces additional overhead, because the uncompressing step will be in-memory and stalls the processing of the file.

Re: What CSS minifiers also leave behind

#15

Post by legulere »

josephg wrote: post #3

The scientific notation one is a bug. Scientific notation isn't part of the CSS spec[1], and its not supported in all browsers. I learned this one the hard way a few months ago. We ran into a flexbox bug in one browser which we worked around by adding some-rule: 0.0000001px instead of 0px. However, our minifier collapsed that using scientific notation, which triggered a rendering issue in a different browser due to t…

Scientific notation seems to be part of CCS3:

https://www.w3.org/TR/css3-values/#numbers

Which browser had problems with it?

Re: What CSS minifiers also leave behind

#16

Post by dkersten »

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…

Does minification speed up parsing (less characters to tokenise)? If so, then minification+compression would be better than compression alone as it would make up a bit for the time spent decompressing.

Re: What CSS minifiers also leave behind

#17

Post by masklinn »

legulere wrote: post #15
josephg wrote: post #3

The scientific notation one is a bug. Scientific notation isn't part of the CSS spec[1], and its not supported in all browsers. I learned this one the hard way a few months ago. We ran into a flexbox bug in one browser which we worked around by adding some-rule: 0.0000001px instead of 0px. However, our minifier collapsed that using scientific notation, which triggered a rendering issue in a different browser due to t…

Scientific notation seems to be part of CCS3: https://www.w3.org/TR/css3-values/#numbers Which browser had problems with it?

"q" is also CSS3, incidentally, and its background is interesting[0]: it's a mostly japanese metric typographical unit[1], it replaces the point, and is slightly smaller: q is 0.25mm while pt is ~0.3528mm (precisely 1/72th of an inch which is 25.4mm).

[0] http://tosche.net/2013/10/font-size-in-the-metric-system_e.h...

[1] although non-japanese typographers like Otl Aicher have recommended its use it doesn't seem to have had much success outside Japan

Re: What CSS minifiers also leave behind

#18

Post by bennofs »

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…

Minifying also speeds up decompression, because less data has to be produced by the decompressor. Compression and minifying are really different optimizations, as the minification does not need to be reversed. So each one has benefits.

Re: What CSS minifiers also leave behind

#19

Post by the_duke »

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…

It will still have a small impact:

-) Less work for decompression

-) Less total length means lexing+parsing will be a bit quicker

-) shorter class names will also mean a lower memory consumption because of shorter strings, and ideally fewer allocations if some pooling or smart allocator is used

But those points can probably be completely ignored, since JS is a way way bigger factor.

Re: What CSS minifiers also leave behind

#20

Post by _9vpl »

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.

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.
Post reply on HN