Performance Optimization for Cascading Style Sheets

As we’ve documented previously on this blog, a majority of perceived Web page load time resides on the front end – i.e., in how a page is rendered to a user. A poorly designed Cascading Style Sheet (CSS) file can have a negative impact on the time it takes a page to display to the user. What’s worse, a poor CSS design might load quickly, but inhibit subsequent performance due to expensive redraw behavior. The following article examines a few key issues in CSS performance, and more importantly, how to decide whether it’s worth the effort in the first place.

Assessing the Web Performance Impact of CSS

A key principle of performance improvement is that any changes should be driven by data. Before tweaking your site’s performance, you need data to tell you which functions or features are causing the biggest delays.

For CSS, the one factor that causes the most performance lags are selectors. Selectors are the statements that specify to which elements a given set of CSS styles will apply. Selectors can be simple, addressing an element by its type:

DIV {
font-weight: bold;
}

Or they can be complex, using a combination of tag name, ID, class and child references to style a specific subset of elements:

Longer selectors generally run more slowly. To profile the running times of selectors, developers can use one of the many CSS profilers available on the Web which will run all of the selectors on a page and calculate their individual running times.

CSS Tips and Tricks – and When to Use Them

First things first: how many CSS includes are on your page? Most Web pages can give themselves a performance boost by using Minify to combine multiple style sheet files into a single file download. This reduces the number of HTTP requests a client must make to the server in order to download a page’s full array of styles.

For selectors, developers can improve performance by following two simple principles laid out by Wouter Bos:

Avoid rules with a large list of descendants. The more complicated a rule, the longer it takes to execute.

Make rules as specific as possible. A general selector like “DIV” will apply to all DIV elements on the page.

As Steve Souders makes clear, however, such performance improvements shouldn’t be made blindly unless profiler data shows that inefficient selectors are slowing down a page. Souders’ tests revealed that, in most cases, revising CSS selectors only results in an average 20ms page performance improvement. Is 20ms significant in web performance? Well, I can’t make that decision for you. It can be easily argued that such an improvement is too small for any users to notice. I will admit that I subscribe to the theory that every performance optimization, no matter how small, contributes to the overall enhancement of the site’s usability. Little speed gains start to add up when you tweak many aspects of the code.

Conclusion

CSS improvements are not the first place I would engage in performance optimization. The tunes described above should be undertaken as a lower priority unless there are visible and measurable problems with a page’s rendering speed – which escalates them in importance.

In terms of overall performance of a web application, focusing on server optimization, caching optimization, and other improvements will usually yield greater benefits. Once all of these improvements are made, developers should use CSS profilers to decide whether their front-end design could benefit from the tips discussed above.