Home » Html » What is the performance impact of the universal selector?

What is the performance impact of the universal selector?

Posted by: admin November 29, 2017 Leave a comment


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"
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
    <style type="text/css">
      * {
        margin: 0;
        padding: 0;
    <h1>This is a heading</h1>
    <p>This is a paragraph of text.</p>

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.


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


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.


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

Avoiding generic selectors will always speed up your page rendering. The wildcard * is slow, especially when your pages become complex nests and your element counts skyrocket.

You should always specify an ID down to the lowest level that you possibly can (I realize that this becomes near impossible especially when dealing with things like database results). But when you use selectors like

.mysuperclass ul li p a

You have a class followed by four generic selectors – that means that for each element of .mysuperclass the rendering engine has to loop through every element in that parent looking for these rules.

In short, my answer is to be as specific as possible with your CSS, and drill down as far as you can into the DOM with your selectors. Avoid wildcards and generics.

Leave a Reply

Your email address will not be published. Required fields are marked *