Remove Universal Selector tip?

[zenorocha]

As pointed by @jonathantneal:

"Tip 21 is a lie".

I started researching more about it and I found some opinions:

Max Howell:

"In modern browsers the performance impact is negligible, provided you don’t apply slow-effects to every element (eg. box-shadow, z-axis rotation). The myth that the universal-selector is slow is a hangover from ten years ago when it was slow." - Stack Overflow

Also this KendoUI article says that Star Selector Not That Bad.

So what do you guys think about it? Should we remove this tip?

/cc @davidsonfellipe @marcelduran @miketaylr @jaydson @sergiolopes @keppelen @mangini

[sergiolopes]

I use the star selector all the time for my resets (to define a global margin, padding, font-size and box-sizing). I have no problem using it, as long as its use is as simple as this.

The main problem with the star selector is abusing it as the key selector in more complex situations — like "header " or "#main article ". This is slow.

And maybe we should make it clear that the rules will apply only when you abuse the antipatterns. I mean, using one single star selector (even if it was very slow) is not a problem (like using .length in one single JS loop, etc). The problem is the abuse.

About the star selector section, I don't think we should remove the rule entirely but maybe merge it with the key selector section and explain its main problem.

[zenorocha]

I agree, sounds like a good plan @sergiolopes.

[marcelduran]

Remenber that Google Pagespeed had not deprecated this rule https://developers.google.com/speed/docs/best-practices/rendering#UseEfficientCSSSelectorshowever they decreased its impact in the overall score. Keep it!

On Monday, March 11, 2013, Zeno Rocha wrote:

I agree, sounds like a good plan @sergiolopeshttps://github.com/sergiolopes .

— Reply to this email directly or view it on GitHubhttps://github.com/zenorocha/browser-diet/issues/49#issuecomment-14724544 .

@marcelduran

[jonathantneal]

Yes, "avoid mixing the universal selector" or "avoid polluting the universal selector".

By itself, it is not - and likely was never - slow. It has bad PR because of all the mixing that was done in the past, as @sergiolopes pointed out, e.g. table * p

I understand the misconception, @marcelduran. Please, note that Google is only erring the * in mixed company.

[cironunes]

Remember also of implicit universal selectors like this:

[class^="button"] { ... }

will be:

*[classˆ="button"] { ... }

[keppelen]

exact @cironunes, not only remove * resolve problem

[OscarGodson]

I came here just to request the same thing.

[coogie]

I agree with removing it, regardless of whether Google Pagespeed still uses it as a rule.

According to Paul Irish's post on using * { box-sizing: border-box; }, it's a bit of a non-issue.

You might get up in arms about the universal * selector. Apparently you’ve heard its slow. *Firstly, it’s not. It is as fast as h1 as a selector. It can be slow when you specifically use it like `.foo > `, so don’t do that.* Aside from that, you are not allowed to care about the performance of \ unless you concatenate all your javascript, have it at the bottom, minify your css and js, gzip all your assets, and losslessly compress all your images. If you aren’t getting 90+ Page Speed scores, it’s way too early to be thinking about selector optimization.

If someone has gone through all the effort of minifying, concatenating, and gzipping all their assets then I would feel it safe to assume they know what they're doing and would, hopefully, be optimising their selectors.

[marcelduran]

If one has gone through all this effort doesn't necessarily mean they know what they're doing. If that was true we should drop most of the hints/rules from this project. Emphasizing .foo > * is bad however would be good.

@marcelduran

On Mar 12, 2013, at 9:04 AM, Stephen Coogan notifications@github.com wrote:

I agree with removing it, regardless of whether Google Pagespeed still uses it as a rule.

According to Paul Irish's post on using * { box-sizing: border-box; }, it's a bit of a non-issue.

You might get up in arms about the universal * selector. Apparently you’ve heard its slow. Firstly, it’s not. It is as fast as h1 as a selector. It can be slow when you specifically use it like .foo > , so don’t do that. Aside from that, you are not allowed to care about the performance of \ unless you concatenate all your javascript, have it at the bottom, minify your css and js, gzip all your assets, and losslessly compress all your images. If you aren’t getting 90+ Page Speed scores, it’s way too early to be thinking about selector optimization.

If someone has gone through all the effort of minifying, concatenating, and gzipping all their assets then I would feel it safe to assume they know what they're doing and would, hopefully, be optimising their selectors.

— Reply to this email directly or view it on GitHub.

[paulirish]

if you do a trace of performance of page load time or in-app performance, the star selector will contribute some miniature fraction of a percent of cost.

Use the Chrome DevTools Timeline. Use Speed Tracer.

For example.. look at the loading of this site itself:

I just ran the css selector profiler in the chrome devtools and the * selector in the site's own CSS (tee hee) adds 4ms over the length of the load time of the page:

4ms would be a lot of that was a recurring cost but by itself it's nothing. compare it to the other values you see in the speed tracer & timeline results:

---

summary: even though the * selector has AN impact, it's so damn small it should NOT distract any developer. and devs write selectors all the time.

there are much bigger things to worry about.

[zenorocha]

Thanks for jumping into this @paulirish.

What about this, we remove this tip (https://github.com/zenorocha/browser-diet/commit/96ff152fea14401c1e6b5d25002970ef91fab914) and add a warning for using the universal selector as the key selector (https://github.com/zenorocha/browser-diet/commit/924dcb57d88da61176043b0c786a7ab6e0c5e788). Here's the final result.

What do you think?

[paulirish]

I would agree on removing the univ selector section. I would also remove the "key selector" tip. And the "selectors" section inside jQuery.

They do not have significant enough impact on page performance to make developers concerned with them. Their distraction ability is IMMENSE and their impact is the inverse.

On Tue, Mar 12, 2013 at 6:25 PM, Zeno Rocha notifications@github.comwrote:

Thanks for jumping into this @paulirish https://github.com/paulirish.

What about this, we remove this tip (96ff152https://github.com/zenorocha/browser-diet/commit/96ff152fea14401c1e6b5d25002970ef91fab914) and add a warning for using the universal selector as the key selector ( 924dcb5https://github.com/zenorocha/browser-diet/commit/924dcb57d88da61176043b0c786a7ab6e0c5e788 ).

What do you think?

— Reply to this email directly or view it on GitHubhttps://github.com/zenorocha/browser-diet/issues/49#issuecomment-14816538 .

[zenorocha]

Created other issues to discuss that.

• Tip #12 - jQuery Selectors - Should we remove it?
• Tip #20 - Key selectors - Should we remove it?

[marcelduran]

I think the key goal of browserdiet.com is to give low-hanging-fruit advices on performance and to be as succinct as possible, hence micro optimization and/or very specific use cases would not add any value as they aren't usually the bottleneck in WPO. That being said I agree we should remove universal selector and key selector tips, however I think it'd be valuable to keep a section that suggests linting CSS through @stubbornella's @nzakas's csslint.net but keep in mind it does warn about universal selector.

[zenorocha]

Yeah, we could add a CSS Lint tip @marcelduran, since they have performance rules like "Avoid selectors that look like regular expressions" and "Don't use too many web fonts".

http://csslint.net/about.html

[robwierzbowski]

As an aside to a comment above, I don't believe "implicit" universal selectors like

[class^="button"] { ... } // implicitly *[class^="button"]

are an issue. Classes and IDs imply the universal selector, but of course we've never had a problem with them; in fact performance wise it's better not to chain an element to an attribute, class, or ID selector.