7

I tested some CSS-compressors and to be honest, I'm disappointed. Maybe I just tried the wrong ones?

Starting point was the following, intentionally bad css-code:

.a{
   font-size: 10px;
   padding: 0 6px;
   text-align: center;
}
.b{
   font-size: 11px;
   padding: 0 6px;
   text-align: center;
}

which is, pretty obvious, nonsense in declaring 2 of 3 properties in both classes and results in 185 bytes of code. If you write it better manually it would look like

.a, .b{
   padding: 0 6px;
   text-align: center;
}
.a{
   font-size: 10px;
}
.b{
   font-size: 11px;
}

which is a bit smaller (149 bytes) or even

.a, .b{
   padding: 0 6px;
   text-align: center;
   font-size: 10px;
}
.b{
   font-size: 11px;
}

which is 133 bytes before and

.a,.b{padding:0 6px;text-align:center;font-size:10px}.b{font-size:11px}

only 71 bytes after compression. This would be 100/185*71 = 38,3% of the original size.

What all compressions did however was:

.a{font-size:10px;padding:0 6px;text-align:center}.b{font-size:11px;padding:0 6px;text-align:center}

which is 100 bytes.

Of course, in an ideal world you would just write better CSS code on the first hand, but that's not easy if you write larger files and almost impossible if you're using any frameworks .

So, are there any better tools out there that result in something like 71 bytes for the above example code?

Artjom B.
  • 61,146
  • 24
  • 125
  • 222
Raphael Jeger
  • 5,024
  • 13
  • 48
  • 79
  • Such tool would be terribly complicate to write and its bugs can potentially ruin your CSS in difficult to spot way—I guess someone wrote one. – Álvaro González Feb 13 '13 at 09:01
  • I agree. While your example is pretty simple and straight forward, imagine a CSS file with hundreds of defined classes where each property is shared by two or more classes. I don't quite believe that this would result in significantly smaller CSS file. – Paul Feb 13 '13 at 09:03
  • 2
    To add to the complexity, the order of rules is important for overrides in CSS. Moving stuff around in a CSS-file without affecting the outcome is not an easy task. – Christofer Eliasson Feb 13 '13 at 09:10
  • 1
    To build upon @ChristoferEliasson's comment, this could only practically compress classes that shared the same properties *that also happened to be next to each other* in the file. Given that compression is key in rather huge CSS files, the actual percentage savings of this technique would likely be insignificant. – DA. Feb 13 '13 at 09:13
  • Reminds me of http://www.csstrashman.com/, which you may already tried, I think. – pdu Feb 13 '13 at 09:14
  • 1
    In other words, this particular means of compression, while valid, would tend to be a really small part of most CSS files. The ROI just isn't there. – DA. Feb 13 '13 at 09:14
  • I don't see why it's overly complex. CSS files are parsed in a straight-down sequential fashion, so every property per selector appearing later overrides it's predecessor(s), with the only exception being "!important"-properties. – Raphael Jeger Feb 13 '13 at 11:19
  • @Paul: exactly when a property is shared among hundreds of selectors it's a necessity to join it in one rule with a longer selection, don't you think so? – Raphael Jeger Feb 13 '13 at 11:21
  • @RaphaelJeger: This is probably true for rather simple class assignments. I was just thinking of my default clients where the selectors are rather long (60+ characters are no rarity) due to hundreds of special cases. So, if the tool you are looking for worked in the way you wish, I would have these selectors repeated many times. But I would settle on that it really depends on the project. Personally, I don't really care that much about the size of CSS files (it's in most cases below 50kB and being cached) but rather focus on CDN and optimization for images. – Paul Feb 13 '13 at 11:50
  • @RaphaelJeger it's incredibly complex. Let's say your first rule is `.a` and your 100th rule is `.b` Do you combine them and place them at the first, or combine them and place them at the 100th position? In either case, there's 98 other styles that may depend on the order of those particular two items. Of course, you can't know that unless you know how the classes are all being used in the HTML. – DA. Feb 13 '13 at 21:52

3 Answers3

2

Gzip the files

By gzipping the .css file on Bargaineering, its size dropped from 28.2K to 7.3K, a 74.1% savings. Response time for that file went from 53ms to 39 ms, a 26.4% savings.

How to GZip CSS Files

Dipak
  • 11,930
  • 1
  • 30
  • 31
1

The compression may seem insignificant, but what else do you expect it to do? Any sort of CSS compressor you can dream up will only take you so far before mangling your code.

CSS is after all, not a programming language.

Jezen Thomas
  • 13,619
  • 6
  • 53
  • 91
  • The definition of CSS will surely change with its version 4. It's coming with formulas, conditions and so on :) – Dipak Feb 13 '13 at 09:11
  • CSS is [already Turing-complete](http://stackoverflow.com/questions/2497146/is-css-turing-complete) ;) – James Allardice Feb 13 '13 at 09:13
  • @Dipaks That doesn't mean selector logic will change though, does it? I mean, you can't use aliases like you might with a JS closure. It also can't optimise selectors, since it would need to know the DOM. Experimental technology like `calc` has no impact on whether or not you can compress CSS more effectively than is possible today. – Jezen Thomas Feb 13 '13 at 09:46
0

When you use gzip after CSS compression (like its suggested by most performance guides) then you have a different results, because the output from the CSS compressors is better zipable.

The CSS compressed version is 85 bytes after gzip and yours is 89 bytes after gzip.

So when using gzip after CSS compression the code from the tools win. Furthermore the result is more like the original code which leaves less space for mistakes due to over-optimization breaking your CSS.

However your CSS code wins in unzipped version with 71 bytes.

The optimization you've done has a very localized use case where the selectors are next to each other in the CSS file.

Some example fiddles showing the problem: 

.a {
    height:50px;
    width:50px;
    background-color: yellow;
}

.b {
    background-color: red;
}

.c {
    background-color: yellow;
}
Fabian Barney
  • 14,219
  • 5
  • 40
  • 60
  • "my code" in this special example wins in every case in an unzipped version against every compressor + gZip, that's somehow "uncool"... – Raphael Jeger Feb 13 '13 at 11:26
  • Well, as @DA. stated in his comment your optimization only works for selectors which are next to each other in the file. Otherwise you may change semantics. I'll add an example where this happens to my answer. So this optimization has a very localized use case. – Fabian Barney Feb 13 '13 at 16:20
  • yup, this makes sense. It would be complex and even depending on where classes get used, right? – Raphael Jeger Feb 13 '13 at 18:33