Efficiently Rendering CSS

css-tricks.com

12 points·cwan··7 comments

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."

Seriously...the bottleneck is NOT the CSS...

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.

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?

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.

> 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.

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

Reply on news.ycombinator.com