What is the performance impact of the universal selector?

html css performance css-selectors

15,389

Solution 1

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.

Reference: http://www.kendoui.com/blogs/teamblog/posts/12-09-28/css_tip_star_selector_not_that_bad.aspx

Solution 2

I understand that wildcards have a performance impact, but on smaller sites the impact is negligible. Wildcards are very useful tools for building a site based on progressive enhancement. Obviously, using something like HTML *, really impacts performance on larger sites, but making it more specific, such as #element_id *, helps to quickly make universal changes to child elements.

The wildcard is there for a reason after all. You just have to understand when using it will be more beneficial than not using it. It depends on the context.

I use wildcards and generic selectors when making CSS templates. It's also a great way of quickly tweaking a range of elements inside an unfamiliar WordPress theme using custom styles.

Even Bootstrap, which is popular and streamlined, uses wildcards under the right circumstances.

References:

http://getbootstrap.com/css/
Gustafson, A. 2015. Adaptive Web Design: Crafting Rich Experiences with Progressive Enhancement. Berkeley, (CA): New Riders.

15,389

Author by

Bungle

Front-End Developer. #SOreadytohelp

Updated on June 06, 2022

Comments

Bungle almost 2 years
I'm trying to find some simple client-side performance tweaks in a page that receives millions of monthly page views. One concern that I have is the use of the CSS universal selector (*).

As an example, consider a very simple HTML document like the following:
```
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
                      "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
    <title>Example</title>
    <style type="text/css">
      * {
        margin: 0;
        padding: 0;
      }
  </head>
  <body>
    <h1>This is a heading</h1>
    <p>This is a paragraph of text.</p>
  </body>
</html>
```
The universal selector will apply the above declaration to the body, h1 and p elements, since those are the only ones in the document.

In general, would I see better performance from a rule such as:
```
body, h1, p {
  margin: 0;
  padding: 0;
}
```
Or would this have exactly the same net effect?

Does the universal selector perform more work that I may not be aware of?

I realize that the performance impact in this example may be very small, but I'm hoping to learn something that may lead to more significant performance improvements in real-world situations.

I don't intend to override the styles in the universal selector rule with other styles later in the document - i.e., using it as a quick and dirty reset stylesheet. I'm actually trying to use the universal selector exactly as I think it's intended - to apply a rule set to all elements in the document, once and for all.

Ultimately, I'm hoping to determine if there is something inherently slow about the universal selector, or if it just has a bad rap due to rampant misuse. If * { margin: 0; } is literally equivalent to body, h1, p { margin: 0; }, then that will answer my question, and I'll know to go with the former since it's more concise. If not, I want to understand why the universal selector performs more slowly.
Bungle almost 14 years

Thanks, Jarrod. I think I could have better emphasized in my question that I do want to target every element on the page with my CSS rule(s) - i.e., the universal selector, as I understand it, is exactly what I want in this case. Since I've also always heard the universal selector to be slow, I'm hoping to learn if that slowness is inherent to the selector, or is just based on its typical usage (e.g., a quick and dirty reset stylesheet that will be followed by styling overrides).
Jarrod Nettles almost 14 years

I see. I would suggest doing some speed tests using Chrome's developer tools. Test it out and see the results for using the wildcard selector versus explicit tag definition. Chrome will give you a breakdown of how long each process takes.
chharvey over 10 years

I would advise against being "as specific as possible" with your selectors. In the future when you want to make changes to styles or when you have more exceptions, you'll want to override those selectors, which becomes increasingly harder the more specific they are. Keep specificity low, and use more element and class selectors. numiko.com/labs/2011/07/css-specificity-wars
Mike almost 8 years

Absolutely agree with chharvey, greater specificity = greater bloat + greater effort to maintain & extend. My general rule is to never use more than 2 levels of nested rules. This is absolutely achievable even on large projects, especially when using a methodology like BEM (getbem.com)
Jiulin Teng about 3 years

This is horrible "advice". It's VERY slow when every nesting element must be searched for. You use .mysuperclass a and that's it.
Huangism over 2 years

True, from years ago but not a myth, it was a reality back then