4 ms·

Show HN: A Genetic approach to CSS compression

63 points by friggeri 14y ago

friggeri 14y ago
OP here, available to answer your questions if you have any.
- ganarajpr 14y ago
  Since GA is non-deterministic, you will never know how long / for how many iterations ( generations) to run the GA for. If one could get a pretty good compression in around 200-500 generations, then perhaps it would be a good solution.
franze 14y ago
however, although the resulting file size is smaller, once gzipped it actually leads to larger files than by only using minification, therefore this is a totally useless article, no, it's not. mobile devices have a relatively small cache size, and assets are cached in non-gzip-ed form. so non-gezip-ed filesize is important (on mobile, that is)
- justinsb 14y ago
  I really appreciate OP's honesty/humility, and (presuming you're right franze) it shows that even things we ourselves consider to be dead-ends, may in fact be useful to different applications. I'd be very happy to see lots more of these interesting experiments - regardless of outcome.
- friggeri 14y ago
  I was not aware of that at all, thanks for pointing it out. Looks like this could actually be a solution to something.
SageRaven 14y ago
Best practice for serving .css files is gzippped? Is this at the file level or on-the-fly by the web server? In any case, why is this considered best practice? (I ask as a sysadmin, not a web developer.)
- sambeau 14y ago
  Generally on-the-fly by the web server, although you can, in theory, zip manually and serve. The big speed bottleneck when serving pages is the network so the smaller the file you send across the wire the faster your page will load. This goes for all the text mime-types: html, xml, css, javascript, text.
- icebraining 14y ago
  While most people do on-the-fly gzipping, I think that's it's best to just include static gzipping as part of the deployment process. Then you can use e.g. Nginx's HttpGzipStaticModule to serve the appropriate version.
halbermensch 14y ago
Quite interesting though, as far as "useless" ideas go.
muxxa 14y ago
What about if you rerun the genetic algorithm with the fitness function being the size of the final compressed+gzipped file? Maybe that could counter-intuitively reorder the CSS so that there are more long runs of repetitive rules which result in an optimum final level of compression.
- friggeri 14y ago
  This is more or less what I hint to at the end of the article, I did look at it very fast but it did not yield very interesting results. The way I see it that this might be related to the fact that there is really no link between the different genetic operators and the deflate algorithm. Anyways, I'd love to be proven wrong, in case anyone wants to fork the repo and try that.
  - muxxa 14y ago
    Haven't run it yet, but a simple change to the cost function: https://github.com/eoghanmurray/css-bipartite-compression/commit/2da0a52cb4968959001acecd7ae3095717ea8534 https://github.com/eoghanmurray/css-bipartite-compression/co... Maybe the assumption to merge more frequently than to split doesn't hold with the new cost function.
    - friggeri 14y ago
      You might be onto something about the merge/split balance. Will definitely investigate in that direction.
merraksh 14y ago
The problem might be NP-hard, but with modern commercial (CPLEX, Gurobi, Xpress) and open-source (Cbc, SCIP) solvers for discrete optimization you can find a provably optimal solution in a relatively short time, even for thousands of nodes. The disadvantage of genetic algorithms is that they are heuristics, with no guarantees on the quality of the solution found. Exact solvers such as the ones above do provide an estimate of how far you are from the optimal solution if you decide to stop them before they terminate.

63 points by friggeri 14y ago

friggeri 14y ago

OP here, available to answer your questions if you have any.

ganarajpr 14y ago
Since GA is non-deterministic, you will never know how long / for how many iterations ( generations) to run the GA for. If one could get a pretty good compression in around 200-500 generations, then perhaps it would be a good solution.

franze 14y ago

however, although the resulting file size is smaller, once gzipped it actually leads to larger files than by only using minification, therefore this is a totally useless article, no, it's not. mobile devices have a relatively small cache size, and assets are cached in non-gzip-ed form. so non-gezip-ed filesize is important (on mobile, that is)

justinsb 14y ago
I really appreciate OP's honesty/humility, and (presuming you're right franze) it shows that even things we ourselves consider to be dead-ends, may in fact be useful to different applications. I'd be very happy to see lots more of these interesting experiments - regardless of outcome.
friggeri 14y ago
I was not aware of that at all, thanks for pointing it out. Looks like this could actually be a solution to something.

SageRaven 14y ago

Best practice for serving .css files is gzippped? Is this at the file level or on-the-fly by the web server? In any case, why is this considered best practice? (I ask as a sysadmin, not a web developer.)

sambeau 14y ago
Generally on-the-fly by the web server, although you can, in theory, zip manually and serve. The big speed bottleneck when serving pages is the network so the smaller the file you send across the wire the faster your page will load. This goes for all the text mime-types: html, xml, css, javascript, text.
icebraining 14y ago
While most people do on-the-fly gzipping, I think that's it's best to just include static gzipping as part of the deployment process. Then you can use e.g. Nginx's HttpGzipStaticModule to serve the appropriate version.

halbermensch 14y ago

Quite interesting though, as far as "useless" ideas go.

muxxa 14y ago

What about if you rerun the genetic algorithm with the fitness function being the size of the final compressed+gzipped file? Maybe that could counter-intuitively reorder the CSS so that there are more long runs of repetitive rules which result in an optimum final level of compression.

friggeri 14y ago
This is more or less what I hint to at the end of the article, I did look at it very fast but it did not yield very interesting results. The way I see it that this might be related to the fact that there is really no link between the different genetic operators and the deflate algorithm. Anyways, I'd love to be proven wrong, in case anyone wants to fork the repo and try that.
- muxxa 14y ago
  Haven't run it yet, but a simple change to the cost function: https://github.com/eoghanmurray/css-bipartite-compression/commit/2da0a52cb4968959001acecd7ae3095717ea8534 https://github.com/eoghanmurray/css-bipartite-compression/co... Maybe the assumption to merge more frequently than to split doesn't hold with the new cost function.
  - friggeri 14y ago
    You might be onto something about the merge/split balance. Will definitely investigate in that direction.

merraksh 14y ago

The problem might be NP-hard, but with modern commercial (CPLEX, Gurobi, Xpress) and open-source (Cbc, SCIP) solvers for discrete optimization you can find a provably optimal solution in a relatively short time, even for thousands of nodes. The disadvantage of genetic algorithms is that they are heuristics, with no guarantees on the quality of the solution found. Exact solvers such as the ones above do provide an estimate of how far you are from the optimal solution if you decide to stop them before they terminate.