Google Speed!

Google has a nice collection of tutorials, tech talks, etc… related to making websites run faster. You can find it here: Let’s make the web faster.  This is no longer available.  Check out a 3rd party guide here: PageSpeed Guide and higher level Google Site here: PageSpeed Insights Rules

I strongly disagree with the first tutorial however. CSS: Using every declaration just once.

The premise of the tutorial is that in order to make your website faster, you should make the code you send to the browser smaller (TRUE) and that one of the best ways to optimize CSS files is to use every declaration just once. This second part is the part I disagree with so strongly.

Basically the author recommends reversing the standard organization of the CSS declarations. Here are the before and after examples from the tutorial:

Before:

[css]
h1, h2, h3 { font-weight: normal; }
a strong { font-weight: normal !important; }
strong { font-style: italic; font-weight: normal; }
#nav { font-style: italic; }
.note { font-style: italic; }
[/css]

After:

[css]
h1, h2, h3, strong { font-weight: normal; }
a strong { font-weight: normal !important; }
strong, #nav, .note { font-style: italic; }
[/css]

So instead of having your selector/class/id contain all of the relevant styling declarations, you group the relevant selectors for each declaration. It’s changing the traditional one-to-many relationship of selectors and style declarations to a many-to-one relationship.

The upside, and the premise of the article, is that this reduces the size of the CSS by reducing duplicate lines of declarations. This is true, but is a very small upside compared with the downside.

The downside of this is that it makes writing, maintaining, and debugging your CSS MUCH harder. The styles applied to a given selector/element/class/id are now spread out over the entire CSS file.

If you’re a Java developer, this is akin to re-factoring every property in every bean you have into their own interface (since Java doesn’t do multiple inheritance) and having each bean implement a huge number of these interfaces. It’s backwards, and makes maintaining your application amazingly difficult.

The other thing is that the CSS file size savings are only 20-40%. If you’re gzipping your CSS files on your web server and setting a far futures expiration header (and you are doing both of those things, right?), then the savings are closer to 2-4%. Totally not worth it considering the downsides above.