April 26, 2014

Efficient CSS

making the browser work less and users wait less #

As I am relatively new to the web development world, I’ve been trying to form good habits from the start. Still, even with less than a year under my belt since I first googled the words, “web design tutorials,” I am realizing that I may have already started to develop some bad practices when starting projects. It is a little intimidating to open up the text-editor and stare at a blank page, hoping to be inspired. So once inspiration strikes, I have a tendency to alternate between haphazardly jotting down CSS rules and refreshing the browser to see if the desired change has taken effect. This process generally results in a disorganized, inefficient stylesheet.

Recently however, I decided to do a little digging - inspired by this article by treehouse teacher, Guil Hernandez - and have learned a few things about how to write CSS that is easier on the browser, and probably a lot less work in the long run. Here are some highlights that stood out to me. This is by no means a comprehensive list. For a more in-depth look, check out Efficiently Rendering CSS, or look at what the browser vendors are saying: Mozilla (this one is pretty old) and Google.

Order of Efficiency #

I wasn’t aware that the efficiency of a selector could vary based on its type, but evidently it can. A list of selector efficiency, from fastest to slowest:

ID selectors
Class selectors
Tag selectors
Universal selectors

    #main-nav {...}    // ID selector

    .social-links {...}  // class selector

    ul {...}      // tag selector

    * {...}       // universal selector

Up until this point I wouldn’t assign an id or class to an except to avoid a huge chain of descendant selectors. Here though, the tag selector is 3rd on the efficiency chain, making it advantageous to use ids and classes wherever possible.

Right to Left #

Another interesting piece of information is that browsers read CSS from right to left. This means that both descendant selectors and qualifiers of selectors are “expensive” operations for the browser, since they force the browser to continue reading, even if it has already found the selector it needs.

/*  qualifier  */

    ul.main-nav {...}       /*  fairly inefficient  */

/*  descendant selector  */

    body ul li a {...}      /*  most expensive selector in CSS  */

Obviously, most descendant selectors are arranged as such so that the browser will know which html element to select, so this type of rule is probably unavoidable at times. Still, when possible, it seems like adding an id or class to a child element would improve efficiency.

As a side note, I don’t know how this applies to SASS since one of its defining features is the ability to to nest descendant selectors within the rule for the parent element. SASS also allows for the use of the ampersand symbol (&) which references a parent selector much like the above example of the qualifier.

Overriding or Repeating Previously Declared Values #

This is probably my biggest issue when putting together a stylesheet, and probably more an issue of disorganization than inefficiency. The cascade is what CSS is all about (it’s in the name after all), so it’s important to take advantage of it. Here are some mistakes I commonly make that can be easily avoided with better planning.

/*  Repeating values  */

    body {
      font-family: 'Ubuntu', sans-serif;
      color: tomato;
      height: 100%;
      width: 100%;
     }

    #main-nav {
      width: 75%;
      font-family: 'Ubuntu', sans-serif;
      color: tomato;
     }

The font-family and color rules declared in the body selector cascade down to the #main-nav and don’t need to be declared again. I’ve realized that paying closer attention to this really helps clean up my stylesheets, and makes them much easier to read.

/*  Overriding Values  */

    h2 {
        font-family: Georgia, serif;
        color: red;
        ...
     } 

/* ======================================*/

    .footer-headline  {
        color: yellow;
     }

Rather than overriding the color rule, it would probably be better not to declare a color in h2. If most h2 elements need to be red, a second class could be created like .secondary-headline and applied to the necessary h2 elements.

“When Possible…” #

Summing up, I would like to throw out a disclaimer. Since I am still new to all this, I imagine there are many, much more experienced developers who would say that they don’t necessarily follow all of these “efficiency guidelines”, which is completely understandable. I think this quote from Chris Coyier really puts it in perspective:

So we know that ID’s are the most efficient selectors. If you wanted to make the most efficiently rendering page possible, you would literally give every single element on the page a unique ID, then apply styling with single ID selectors. That would be super fast, and also super ridiculous. It would probably be extremely non-semantic and extremely difficult to maintain. You don’t see this approach even on hardcore performance based sites. I think the lesson here is not to sacrifice semantics or maintainability for efficient CSS.

In the end, I am trying to learn the best possible practices, and at least keeping these guidelines for “efficient CSS” in the back of my mind seems like a good place to start.

Kudos