When coding CSS, one of the best ways to ensure your code runs smoothly on older browsers and slow computers is to write your CSS efficiently for browser rendering, this way your site takes less resource and memory from the user’s computer and therefore runs smoother.

Browser vendors constantly trying to make rendering faster, the faster pages load the happier people are using their products. Google is always on a crusade to make the web faster. Mozilla also has several articles about best practices.

In this posting we cover some of the big ideas they present, and then discuss the practicalities of it all.

Ways to Speed Up CSS Rendering

Avoid reflow and repaint by specifying image dimension

To avoid unnecessary reflows and repaints, always specify a width and height for all images, it allows the browser to render the page even before images are downloaded, otherwise the browser will require a reflow and repaint once the images are downloaded. You could specify the width and height of all images, either in the HTML img tag, or in CSS. If you need smaller images, scale it in an image editor and set its dimensions to match, avoid using width and height specifications to scale images on the fly.

Universal Selectors are the Least Efficient, ID’s are the Most

Here are selectors according to rendering speed:

#sidebar  {}       	     /* ID (Fastest) */
.home #slider {}         /* ID */
.footer {}               /* Class */
ul li a.arrow {}         /* Class */
ul {}                    /* Tag */
ul li a }                /* Tag */
* {}                     /* Universal (Slowest) */
#content [title='home']  /* Universal */

For example this selector isn't very efficient:

#sidebar > li

Since IDs are the most effective, you would think the browser could just find that ID quickly and then find the li children, but it won’t speed up the rendering speed since browsers render selectors right to left.

The Principle of Right to Left
It's very important to understand how browsers read your CSS selectors. They read CSS from right to left so the selector ol > li a[title="link"] the first thing interpreted is a[title="link"] (it is also referred to as the "key selector").

It’s good to know that as soon as the right-to-left interpretation of a selector fails a match, it stops trying, and so expends less energy than if it needed to keep interpreting. However, you should always remove unused selectors in your code.

Move link Elements from the Document Body to the Document Head

Always put external CSS and style blocks in the head section. Specifying external stylesheets and inline style blocks in the body of an HTML document can take much more time for the browser to render the document.

Descendant Selectors

The most expensive selector in CSS is the descendant selector. It is terrible expensive, particularly if it is in the Tag or Universal Category. For example, a selector like this is a very bad choice:

html body nav a span {} 

Take Advantage of CSS Cascade

Sometimes you can achieve your desire result without using extra selectors. For example consider this code:

nav li a {font-size:14px}

Since font-size cascades, you don't need to specifically declare your CSS and it is far more efficient:

nav {font-size:14px}

Overly qualified selectors

Don’t do this:

form#UserLogin {}

ID selectors are unique; it just makes them less efficient as they don't need a tag name to go along with it. Classes aren't unique, but it’s a good idea to avoid this method on classes too.

CSS3 Selectors

CSS3 selectors (e.g. :first-child) are amazing in helping us style the elements while keeping our code clean and semantic. But in fact these fancy selectors take more browser resource to use. The sad fact about these selectors is that you shouldn’t use them at all if you care about page performance.

Speed vs Practicality

To achieve the most efficient rendering for a given page, one might simply go overboard giving every single element on the page a unique ID and applying styling with single ID selectors. It is extremely non-semantic and extremely hard to maintain. Even hardcore performance based sites don’t sacrifice maintainability or semantics for efficient CSS.

You could as well follow them, but you shouldn’t to be all dogmatic about it. It may be worth revisiting your CSS and look for where you can do better especially if your target audience is mostly on mobile devices with limited computing power, this can be a lifesaver, otherwise don't worry about it.

Conclusion

These best practices require some upfront investment, but the cost is small - especially in comparison to the gains. And once these improvements are put in place, they continue to boost performance over the life of the development process. I hope you’ll find these rules to be elegant improvements that benefit you and your users.