If a designer knows some of these tips at the beginning of the design process, and is able to complete the initial design with them in mind (assuming time remains constant), then I'd argue "premature optimization" isn't an issue, but the end output is still faster.
No optimization is intrinsically premature. Most of these are not things you need to worry about, but there will be cases where it makes a different.
That said, specifying image sizes is often a good idea in order to prevent the page from moving around while it loads. It looks a lot cleaner if your text all flows correctly and then the images pop into place.
What developer isn't getting 90+ page speed scores these days? That stuff is trivial low-hanging fruit that rarely requires rearchitecting your application or page.
Wonder why such an article came up on HN startpage. There are no tests showing the effort of this performance tips, or how much this is true for different browsers. Is the CSS selector performance a real world problem in all browsers and all pages or only for large pages in mobile browsers? The article gives no answer.
Unless you are talking about mobile devices, there are so many other things one needs to look into before trying to tune the CSS for getting better performance. Stuff like gzipping, caching and CDN will all contribute to page load performance in a much more significant way.
I visit websites that will make my CPU max out when I scroll pretty much every other day. If this guide is related to that, then it is definitely worth it.
9 times out of 10 it's related to JS or some sort of external embedded resources. The other big culprit tends to be box-shadow which have pretty horrific performance in Chrome[1], but don't do that well in other browsers either.
I find that selector performance is not a problem unless you're dealing with large-scale one-page apps.
Yeah, definitely JavaScript. Don't forget web fonts too. I can't tell you how many times I see an entire page load then have to wait several seconds for any text to show up. It's always good to write clean efficient CSS but I think articles like this are more like coder porn than anything else. The performance gains are trivial especially when compared to JavaScript, embeds/like buttons, videos, images, and slow database queries. I know DB queries arent rendering related but I know many somewhat experienced developers working on sites that run a CMS who start optimizing everything except their database and drive themselves crazy trying to figure out why pages are loading so slow. Point is, optimized CSS is probably not that high of a priority for the vast majority of sites.
A lot of things on websites these days take their toll. Facebook js files (like boxes etc), google ads and google maps are really heavy. It also happened on my own sites to have issues with facebook components loading very slowly.
I mean if you consider that just to have a facebook like box it involves loading a JS file, that then scans the page for FBML and then replaces it with an iframe (which also causes the page to repaint because its size is set after the dom is ready) and then the iframe requests 10+ additional files from facebook you understand why some pages take so long to render.
The only time I've ever seen CSS make a difference to page rendering speed is the use of large drop shadows (e.g. 25px wide, on page-size elements) on large DOM elements. Just five of them kills scrolling performance.
Anything else, page rendering times for me have only ever been slowed by too many DOM elements (> 1000). I've never come across a real-world case of the actual selector syntax making a difference.
if you are developing websites for clients don't get into this much detail cause no one will ever appreciate the work you made.
on the other hand if you are running a single web app and have the time to spare it might be a good idea to look into this cause apart from nice visuals and intuitive UI, the more responsive your web app is the more likely users will not give up on it.
>if you are developing websites for clients don't get into this much detail cause no one will ever appreciate the work you made.
That's only true if you don't know how to sell yourself. Considering that you can make people think something is faster just by telling them that it is so, you should be able to get appreciated for actually making a difference.
But don't do this kind of thing in the course of your development. If you make something 10% faster without being asked, nobody is going to appreciate that. Fine-tuning and optimization is a separate service, and if you set realistic expectations and then deliver on them, your efforts will be appreciated.
Though I'd like to have seen some stats on improvements in speed, etc. etc. I agree with most of the comments that optimizing for css selectors is probably overkill.
But being aware how browsers are interpreting your CSS and being a bit mindful during development can be helpful.
form#UserLogin {}
ID selectors are unique; it just makes them less efficient as they don't need a tag name to go along with it. Classes aren't unique, but it’s a good idea to avoid this method on classes too.
Re: classes - at least in IEold, and at least with jQuery, I found that performance for a selector like table.foo was orders of magnitude faster than .foo (for a page with a too-large DOM). IEold does not have a native document.getElementsByClassName so jQuery was searching the entire DOM for a .foo. This may be different for CSS vs JS though.
I find it really interesting how expensive it is to have <img> tags without specifying a width/height. I always knew this was best practice, then stopped doing it once I started experimenting with "responsive web design."
You probably know this but you can just specify something like "height: auto; max-width: 100%;" within a media query if you have an image that's supposed to at most fill the full column width. That would then override the inline height and width attributes.
Paul Irish said related to this: "If aren't getting 90+ Page Speed scores, its way too early to be thinking about selector optimization"
http://paulirish.com/2012/box-sizing-border-box-ftw/#comment...