CSS performance vs SASS nesting and @extend

I subscribe to the Treehouse newsletter, so should you, there’s always a link to something worth clicking. One such post this week was mostly about CSS performance, check it out here. A section that caught my eye was about “Complex, Overqualified Selectors”, for example:

.wrapper .main .post a {...}

This got me thinking about SASS, and how it outputs CSS. Quite honestly, I never even look at the compiled CSS these days. But heavy use of @extend and nesting looks like it could slow the site down as SASS may output a long list of selectors and elements.

Yeah, but CSS is fast

Firstly, I think this is a micro-optimisation topic. CSS is interpreted super fast, and although it is important to keep it as concise as possible, I think streamlined workflow trumps compiled output. However, I’m going to think more about use of extend and nesting.

I think for @extend, I’ll keep it to clearfixes and other global utilitarian styles, to be fair I don’t use it very often anyway. And nesting, which I love and is super powerful for modular sites, I may keep to one selector deep.

An extreme example of the heavy way:

.sidebar {
	...styles...
	.someWidget {
		...styles...
		h4 {
			...styles...
			a:link,
			a:visited,{
				...styles...

			}//a
		}//h4
	}//someWidget
}//sidebar

The link styles would output to this, which is pretty obnoxious:

.sidebar .someWidget h4 a:link, .sidebar .someWidget h4 .a:link {...styles...}

The lighter way:

.sidebar {
	...styles...
	.someWidget {
		...styles...	
	}
	h4 {
		...styles...	
	}
	a {
		...styles...	
	}
	a:visited {
		...styles...	
	}
}//sidebar

Which means the links would compile to:

.sidebar a, .sidebar a:visited{...styles...}

Much better, and less “expensive” so browsers don’t have to parse too many selectors, but maintains the modular benefits of nesting. Everyone’s a winner.