4 ms·
Efficiently Rendering CSS
- kilian 16y agoWhile 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 16y agoThe 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 16y agoI 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.
- isleyaardvark 16y agoThis 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 16y agoSeriously...the bottleneck is NOT the CSS...
- aw3c2 16y ago> 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 16y agoNitpick: selector matching is done before rendering, so it doesn't actually affect rendering speed (changes that affect opacity and clipping would).