

Efficiently Rendering CSS - cwan
http://css-tricks.com/efficiently-rendering-css/

======
isleyaardvark
This is Premature Optimization: CSS Edition.

He buries the lede further down: "That Mozilla article I linked to at the top?
Literally 10 years old. Fact: computers were way slower 10 years ago. I have a
feeling this stuff was more important back then." and "I think the lesson here
is not to sacrifice semantics or maintainability for efficient CSS."

~~~
wdewind
Seriously...the bottleneck is NOT the CSS...

------
kilian
While true, you'll need a _whole lot of_ slow selectors before your CSS will
be the speed bottleneck.

It's more noticeable if you use jQuery/other complex javascript DOM selectors,
but the solution there is caching or using .find(). JS dom querying is also
going native with QuerySelectorAll, so in time it will become less of an issue
here, too.

Write your CSS for yourself, make it maintainable and easy to read. Let
browsers figure out how to make it fast.

------
proee
The article is a bit meaningless since there are no benchmarks for these so
called "best practices"

Are you going to spend hours optimizing your stylesheets to only save 50ms?

Does anyone have a link to a article with true benchmark numbers?

~~~
anatoli
I don't have the tests on hand, but I did some benchmarks back in 2005 or 2006
and the difference was about 100ms for tens-of-thousands of nested tables and
divs and what-not.

So, yeah, doing any of this stuff is just a giant waste of time.

------
aw3c2
> ID’s are unique, so they don’t need a tag name to go along with it. Doing so
> makes the selector less efficient.

I do it (for example div#header) because it helps me knowing what is what in
my CSS. I don't see anything wrong with it.

------
pornel
Nitpick: selector matching is done before rendering, so it doesn't actually
affect rendering speed (changes that affect opacity and clipping would).

