Different CSS techniques and their performance

Why would I want to test performance of CSS techniques?

Here’s the background:
I am a big fan of OOCSS, (the library and the concept) but I have been using Compass, SASS lately at work. I was feeling that sometimes OOCSS and SASS seemed at odds. A friend of mine introduced me to Chris Eppstein, (the creator of Compass) and we talked about the @extend method in SASS. So I created a CSS test page, which started out as a crude way to figure out if there was a noticeable performance difference between SASS’s @extend and OOCSS’s method of CSS.

How the test works

The test makes almost 2000 boxes, all with unique backgrounds (and style rules). There are a few formats for testing (seen in the links below), and you can change to each, and test the speed differences.  Just click the links according to the style you desire.

The test uses a small script I found while researching into this test.  The script comes from Steve Souder’s blog post: Performance Impact of CSS Selectors

Steve’s post goes into a more granular approach of css selector performance, it’s worth the read.

CSS Formats

  1. OOCSS (likely fastest) double class ie.. class="box box-#" and put the base css rules on the .box class then only add the background to the unique classes
  2. Sass @extend (unsure of speed) one class ie.. class="box-3" and create a multi-selector rule with the base rules ie. .box-1, .box-2 {generics}
  3. Blatantly Bloated CSS: add all the base css to each uniqe css file. not DRY
  4. Using ID selectors Although I dont suggest this as a best practice.. it’s worthwhile for testing
  5. No CSS makes for a good baseline for testing

Code samples?

OOCSS style: one master class that holds all common rules, then an additional class for unique rules

.box {padding:25px;border:1px solid #000;border-radius:5px;}
.box-1 {background-color:#FFEE00;}
.box-2 {background-color:#00FFee;}


@extend style: add all unique classes to one, comma separated list of classes that use the base.

.box-1,.box-2 {padding:25px;border:1px solid #000;border-radius:5px;}
.box-1 {background-color:#FFEE00;}
.box-2 {background-color:#00FFEE;}


Long (or Bloated) styling: add all the common rules into each unique class separately

.box-1 {
  border:1px solid #000;
.box-2 {
  border:1px solid #000;


No CSS: kinda self explanatory

Testing Results

The testing results were quite interesting..   Lets check out some charts shall we?

So lets talk about CSS performance first.  Here are some things I see:

  • Using class selectors is almost identical speed to ID selectors
  • SASS/Compass’s @extend format is only slightly behind OOCSS format
  • The bloated format is orders of magnitude slower than the other formats
  • Even in this somewhat extreme example, the difference from best to worst is 100-200 milliseconds

And some notes on the browsers’ performance: (extra credit)

  • Most the browsers behaved about the same, just some were slightly faster
  • Firefox was the slowest of the browsers tested
  • Opera was fastest with fast CSS and slowest with slow CSS

I personally have come to two conclusions after doing this test.

  1. OOCSS and @extend format are very fast
  2. CSS Bloat does hurt performance

Oh.. and here is the test page


I found some discrepancies in the testing that could affect testing, so I have removed any external file references and css rules that are possible performance gotchas (like text-shadow).

Don’t use ID selectors in CSS

Lately I have been testing out performance among css styles and I found that some of my very smart friends, started asking,”why aren’t you testing using IDs for the unique sections of the page?”.

This wasn’t a hard answer:

  1. The element is not re-usable on that page.
  2. This is the begining of a downward sprial into specificity
  3. Usually, IDs refer to something very specific, and abstracting would be tough
  4. Any performance gains picked up by using id, is negated by adding any other selector to the left fo that id

Lets delve into each of these issues at more length

The element is not re-usable on that page:

IDs are programmer’s equivalent to singletons.  There can only be one instance on the page.  This means there is no way to re-use it.  It’s usually a one to one relationship, and according to my speed testing, one line of css that’s only usable once is not a good value.  There IS a cost to css bloat.

This is the beginning of a downward spiral into specificty:

There are two main ways of overriding in css.

  1. The cascade: (anything further down the css, can overwrite the previous css rules)
  2. Specificity: the idea of creating weight by using weighted selectors.

The reason I say that specificity is a downward spiral is because the only way to overwrite a weighted rule is to add more weight..  plain and simple.  Now I am not just saying this because I heard it somewhere.  I have made and paid for this mistake.

.ModuleOfficeList .property-checkbox input
{display:block;margin-bottom:8px;_border:0px !important;}

.ModuleOfficeList .property-checkbox,
  .ModuleOfficeList .new-icon,
  .ModuleOfficeList .open-icon
.uid-officelistings .property-checkbox
{display:none !important; }

Above is real code from one of my own work from 2005.  As you can see, after awhile, I had to resort to some weighty selectors and the !important rule. This is very bad. Once we get to this point.. it takes us more time to hunt down the parent IDs we are going to use in order to overrule the current specificity. This is not team-friendly and definately not maintainable. Eventually you will specify yourself into a hole, and refactoring out specificity is nothing short of a nightmare.

On the other hand:

I have heard a few reasons why using IDs as selectors is a good thing. I’ll speak on them briefly:

Using ID selectors is faster
Yes, using ID selectors is faster than using class selectors for the simple reason that there can only be one id within a page. I even prove that is true, however the performance benefit is very small, and as soon as you add any other selector, the performance benefit is lost.

#profile-module {...}
#profile-module li {...}
.profile-module li {...}

The second selector is no faster than the third. That’s because CSS is read from right to left. so the
gets scanned first, which negates the speed of having an ID. Steve Souders explains how selector speed works.

IDs are meant for singletons
There are times when someone intentionally wants something to be used only once on a page. ID selectors would be useful for that purpose since they would signify once per page. My only argument here is my personal preference of having all my code be re-usable; especially since I don’t see CSS in a “programming language” way.

UPDATE: maintaible CSS / semantic HTML
There is a quite a huge following that believe using IDs are very helpful in creating maintainable CSS as well as creating a more semantic document in HTML. I think that Matt Wilcox sums it up best in his article about naming ID and classes properly. Matt brings up some valid points as reason for using IDs.

Update: Another Article advising classnames over IDs
A year after my initial post, Oli Studholme also made this post about ID selectors as well. We came up with similar conclusions. Thanks Oli!

Honorable Mention
It’s also worth mentioning, that I am not advocating getting rid of IDs from your markup alltogether. IDs can help speed up your javascript and they can relay meaning to your document.. all good things.

But in for CSS, I suggest not using id selectors. There are others that believe using id selectors do have purpose, however I dont find the good outweighs the bad. In the end, the choice is yours to make.

Using the window.location property in Javascript

I often forget how this works, so here is the different properties of window.location.
Thanks to DevGuru for the data.

To see how these work, pop open your firebug and add them to your console box and run them.

The properties:


The hash property is a string beginning with a hash (#), that specifies an anchor name in an HTTP URL.


The host property is a string comprising of the hostname and port strings.


The hostname property specifies the server name, subdomain and domain name (or IP address) of a URL.


The href property is a string specifying the entire URL, and of which all other Link properties are substrings.


The pathname property is a string portion of a URL specifying how a particular resource can be accessed.


The port property is a string specifying the communications port that the server uses.


The protocol property is the string at the beginning of a URL, up to and including the first colon (:), which specifies the method of access to the URL.


The search property is a string beginning with a question mark that specifies any query information in an HTTP URL.

Loading your javascript files asynchronously

So it’s widely understood now, that performance has a direct effect on the traffic of our site.   This puts performance at a much higher priority than before.. especially if your site traffic is what pays the bills.  Steve Souders began working on website performance, initially thinking that backend performance was the key, but he quickly found out that most of the performance could be gained on the front end, with far less work than optimizing sql queries and refactoring backend code.  Since he started publishing his work, we have seen a progression of understaning what helps our websites perform better.  Here is a list of things that we can look to accomplish quickly and see vast performance improvements.

  • minification of files
  • zipping css / js files
  • pulling all css files into one
  • pulling all js files into one
  • creating image sprites that combined many images into one big sprite
  • avoid using IE specific css expressions
  • using a cdn to serve files
  • loading js at bottom of page
  • serving files from a different domain
  • serving files asynchronously after page has loaded

Want to know more about the above performance enhancements?  Go to the Yahoo Developer article explaining them in detail.   Also keep in mind that your mileage may vary.  We found this out at my current job, since we took are most popular pages, and removed all the less important parts of the page, and added them via ajax, after the page loaded.   This made the pages load screaming fast!  However, our server peaked out very quickly because it was doing about 5 times the amount of requests.  Each ajax request, even when cached, requires resources from your server.  Needless to say, we don’t have the money to drop into several more servers, so lazy loading via ajax will have to wait. Keep things like that in mind when adding performance techniques to your site.

Okay Okay, get on with it!

So you have an idea of whats going on with website performance, and the last part of the list was about serving files asynchronously after page load.   Here is a little script that simply loads files after the page has loaded

And to load these files, you only need to call the function with the script as the argument

Really, that’s about it. Fairly simple script as you can see, yet very powerful, this was basically borrowed from Google Analytics implementation of their asynchronous loading analytics.
One thing to note: I am loading the files in the opposite order than usual. The jquery.js file should be loaded first in the dom.. but since we are using insertBefore.. the first must be last and the last must be first.

TextMate command: dummy text generator instead of lorem ipsum

I hate having to go to a page every time I need dummy text like lorem ipsum. So I searched out for a random dummy text generator for my beloved TextMate. Unfortunately, the ones I did find, required another language installed, like Ruby, so I looked into creating one for bash. (since bash is installed by default and it’s the default language for making TM commands.

I created array’s of dummy paragraphs, then I echoe’d one of those paragraphs randomly.
Here is the code.

ARRAY[0]="Auf ya strudel octoberfest hinder ..."
ARRAY[1]="Auf nine die stoppern nine nicht ..."
ARRAY[2]="Sauerkraut leiderhosen du er strudel ..."
ARRAY[3]="Poppin stoppern pukein, frau mitten ..."
ARRAY[4]="Verboten handercloppen zur hast spitzen ..."
ARRAY[5]="Glockenspiel flippin oof sparkin achtung ..."
ARRAY[6]="Rubberneckin blitz pretzel weiner heiden ..."
ARRAY[7]="Ya frau sightseerin noodle thinken stoppern ..."
ARRAY[8]="Deutsch, unter der meister spritz pretzel ..."
ARRAY[9]="Bin octoberfest sauerkraut meister hinder ..."
echo ${ARRAY[((RANDOM%10))]}

and here is how to add it to your Textmate or BBEdit.

Textmate's command editor window with all it's settings

Textmate's command editor window with all it's settings

So I hope that helps, for those of you whom want an easy way to add dummy text to their coding.
type “lipsum” and press TAB..

Oh you say, you want to know where I got the dummy text?

That’s pseudo-german, using the Greeking Machine at Duck Island.

Or get regular Lorem Ipsum at www.lipsum.com.

Simple jQuery show / hide script

I know, I know..  this is a really simple process for those of you who have had more than an hour with jQuery.  But this article’s intention is to show just how quickly and how easily you can utilize jQuery’s robust features that make it so easy and fun to use.

So I am going to keep the explanation short and sweet. I think the code speaks for itself for the most part.

$(document).ready(function(){... does as you would think. Waits for the document to fully load.

$('.hide').hide; finds all elements with the “hide” classname and actually hides them. I am using this as opposed to hiding the elements via css so that those with javascript turned off will see the elements that are hidden. If I used css to hide the elements, then anyone with javascript turned off but have a css capable browser, would have a dysfunctional experience. Hiding elements via javascript ensures that those without javascript will still be able to see the hidden paragraph. nuf said, I think

From there, we are finding #link1 and adding a toggle when clicking. I love this because I dont have to find out the toggle status myself. I just add the two different toggle scenarios, separated by a comma, and I am good to go.

$(this).next() is how I get to the element I want to change. In this case, it is the node / element below the link that has been clicked. I kept the traversal code generic so I could use this anywhere. The only worry I have, is to make sure that the element to show / hide is precisely below the link which it relates to. This simple technique makes the code re-usable.

Next, I am using another of jQuery’s strengths by “chaining” my code to run on click. I do this by using dot for each new behavior I am passing.

.slideDown('slow').removeClass('hide').preventDefault; does three things:

  • gives the element a slide down effect when showing
  • removes the hide class from the element
  • prevents the default behavior of the link

and that’s it!

JQuery uses very simple and familiar syntax for CSS developers and it uses techniques that make it much easier to focus on what you want the page to do as opposed to figuring out how to make it work.



Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

How to get rid of saddle sores in cycling

I wanted to share this because I had quite a time with saddle sores last year, and I found a cheap and easy way to remedy the problem. It’s a bit unconventional, but works like a charm.

Here is the story of last year’s saddle sore issue.
My first year into riding, I bought a beginner’s roadbike, a Bianchi Brava, which served me very well.
I bought the bike and replaced the Bianchi seat with a Serfas gel seat. The semi big one with the gel top and an inset to help alleviate pressure on the private parts..

Now let me start off by saying that most of my riding problems came from inexperience and lack of knowledge. That and inproper fitting to my bike. The road bikes of today are so well made, that it is hard to find a problem with the bike… more-so, it’s a problem with the rider.

Oh yeah… gel seat… I was getting more and more fit, so I decided to take a ride with one of my more experienced cycling friends. We rode about 60 miles that day. The saddle sores were are result of that ride and for quite a few reasons.

1. I needed to have some kind of chamois cream for that area between the private parts, that can trap humidity and use it to “wear down” your skin and allow bacteria growth.

2. I needed to wash up as soon as I was done with the ride and make sure to wash the particular area of question. (fairly common knowledge, but it’s still worth noting)

3. I needed a seat / saddle that fit my butt/legs correctly.

Funny enough, the cushy saddles that would seem to be a savior to your butt, are more commonly the cause of problems such as saddle sores. They are typically too wide for your legs to move around freely and they cause chafing on the inside of your legs.

This is what happened and I tried all kinds of creams on the market to fix the problem. It only kept getting worse. Some of those creams are expensive too! So I tried something totally unconventional and i rolled up some toilet paper like a sleeping bag, and then stuck one on each side of the inside of my legs. ( using boxers wont keep the TP there, so use tightey whiteys)
I left the TP there for several hours and got another batch. I did this for two days and the problem was gone. Very nicely done.

The cost of the TP was close to 10 cents for the problem and it’s always available.