What is the Performance Cost of ‘undefined’ CSS Properties in the DOM?

2 Views

CSS Selectors performance has been emphasized a lot, with good recommendations to:

  1. Use efficient selectors.
  2. Remove unused CSS rules.
  3. Remove any inline style blocks containing CSS that is not used by the current page.

However, no specific reference has been made to avoid unnecessary ids (for the sake of IDing everything like WordPress tends to do) in the DOM. Such as rather fat menus like this:

Read More
    <div id="nav">
      <ul id="menu-main-navigation" class="menu genesis-nav-menu menu-primary">
        <li id="menu-item-22" class="menu-item menu-item-type-custom menu-item-object-custom menu-item-home menu-item-22"></li>
        <li id="menu-item-29" class="menu-item menu-item-type-post_type menu-item-object-page menu-item-29"></li>
        <li id="menu-item-30" class="menu-item menu-item-type-post_type menu-item-object-page menu-item-30"></li>
        <li id="menu-item-118" class="menu-item menu-item-type-post_type menu-item-object-page menu-item-118"></li>
      </ul>
   </div>

It feels like a lot of unnecessary HTML parsing and matching to find css ID rules that don’t exist, or barely used classes that exist by default for no good reasons (e.g. the menu-item-# classes here), on top of the constant unnecessary bytes downloaded for EVERY page. It appears possibly worse that unused css rules in a single cached css file downloaded only once. Or if not worse, isn’t that significant enough to recommend avoiding?

Or Modernizr bloat cases like this: 

<html data-env="production" lang="en" xml:lang="en" style="" class=" js flexbox flexboxlegacy canvas canvastext no-touch postmessage hashchange history websockets rgba hsla multiplebgs backgroundsize borderimage cssanimations csscolumns cssgradients cssreflections csstransforms csstransforms3d csstransitions fontface generatedcontent video audio localstorage sessionstorage webworkers applicationcache overthrow-enabled">

Any browser expert view on this, and how bad it is for performance, compared to unused external rules.

Post Views: 2

Related posts

Leave a Reply

2 comments

  1. If I’m not mistaken, modern browsers add CSS ID and Class selectors to their own hash maps while parsing the CSS. Then when applying the CSS on HTML elements with an ID, it searches the ID hash map for the ID (O(1) or O(lg N) complexity depending on browser implementation). (Classes would work the same way.) So actually seeing if there is styling attached to an ID or Class is really quick (constant or logarithmic time).

    If this is indeed the case, the time spent looking at a bunch of “undefined” IDs and Classes would (in my opinion) be pretty negligible in such a case. This is probably why no one mentions anything about “undefined” ID and Class usage.

    Here’s one website mentioning it. (Find hash map on the page)

    The extra amount of bytes downloaded for those “undefined” IDs and Classes is a debate in itself I suppose. I’d be more worried if there was no compression being done on the web pages server side.

  2. This is an interesting question, web developers know they have to make websites as light and fast as possible for a lot of reasons.

    There are many aspects of a website that can (should) be optimized like image sizes, js minimizing, css minimizing, caching elements…

    But I think we should separate things at least for 2 cases:

    1. CMS/Frameworks that work out of the box for non programmers but still have to be customizable:

      • like in your example: wordpress: wordpress themes tend to have a lot of css elements but they offer an easy to do, high customization level that will for sure suffer if the code were as optimized as possible.

      • You can consider themes as the basic form, if you are a developer you can start from any theme, create your child theme and optimize it.

    2. Everything else that a programmer has to work on in order to make the webapp work:

      • this is like in the second case above, if a dev can code anything then he can optimize it as much as he wants.

    Ok, that was a little bit off the question topic but I think it was worth mentioning.

    Back to css weight:

    The css file: a large css file is probably about 20kb and this adds weight to your site. This can be cached and comparing this with image sizes doesn’t feel like a big weight but when you are doing your best to speed up a website then you have to make everything as small as possible.

    About the inline css weight: if a big css file is about 20kb, the css that is inline/added without a reason(that is not matched) will bring some extra kb, but I really think they can be ignored on a complex html that also uses images and js and jquery the css will probably be less then 5% as weight in kb.(I’ve searched the web for any info about % of html, css, js but didn’t found anything the 5% is what I believe to be a maximum but the real value might be different: a research would be nice…)

    Css matching done by the browser:

    • less css, less code to match, a faster page… but let’s think at js and jquery: lots of matching and even operations done very quickly. This shows that again, you can optimize the code but it won’t count as much as spending your time on optimizing other things (like images, js, queries…)

    So this is what I’ve learned when I’ve tried optimizing websites:

    • spending time on optimizing inline css, reducing it as much as you can won’t count as much as spending that time optimizing other things. But a difference(small or even undetectable in speed) will always be when you use a better optimized css code in the webpage.