Understanding Knowledge as a Commons

science sessions

rs love

Design

A destination to share insights about web development and how to honor the craft.

Web Development

Futureland

rs-devlog

Climate

Rules for Rulers

power

nss code of conduct ad hoc committee

Genesis

Investment

Mydora Myspace streaming service

Music Supply

Trusted Friends Only

A Universe

experiment

In my experience, engineering teams often neglect writing performant CSS. This neglecting has an adequate reason because there are better areas to apply developer resources that have much greater ROI. However for large applications, using certain techniques can provide noticeable performance gains. Everyone can celebrate that.

Luckily for us, this is a simple topic. And most likely you can still use your favourite preprocessor and postprocessor after reading this.

A tree is created called the CSSOM. It stands for the CSS Object Model. Here is a brief overview of how your browser creates the CSSOM:

Read the raw bytes of the CSS or network and translate them into characters based on your system's encoding.

Browser converts strings of characters into tokens.

The browser transforms tokens into objects that hold properties and values.

Objects are composed to form a tree based on their abstracted child, sibling, and parent relationship.

The product is a tree that the browser can use to determine the most applicable rules for any given DOM tree node.

Building the CSSOM is render blocking on the browser's main thread because it locks to finish this task. It's usually fast, but there are a couple of caveats. First of, if there is a lot of CSS, this can take longer than expected. Second, the browser builds the CSSOM each time you load a new page (shout out to the single page apps!).

So the point is: there are a couple of ways to improve this process regardless of what CSS church you belong to (Tachyons, OOCSS, ACSS, BEM, SMACSS or some other well thought out one). We are going to do this by reducing the amount of CSS we write, and making it easier for the browser to create the CSSOM.

Remove the duplicate properties, remove the empty rules, trim your CSS reset down, and remove any selectors that you are not using. This tactic is where you will find the most ROI on a large codebase.

/* divs are already blocks so delete this */

CSS selectors get evaluated from right to left, and for each selector, the browser checks the DOM tree until it reaches leftmost selector. Based on the complexity of selectors, this is a complexity for creating the render tree.

Google page speed recommendations consider descendant selectors, and child or adjacent selectors to be slow. Therefore when it is possible, try to keep all of your class selectors at the top level to keep evaluation fast.

Note: IDs are very performant in CSS, but this rule suggests that you should avoid styling ID in your CSS. I agree with this because each ID represents a unique instance of an element of your code, so its usage is counter intuitive towards reusability and modularity (debatable if you're using SASS mixins for reusability).

/* also viable if using SASS preprocessor */

Since we know the number of selectors used is a performance bottleneck. Do not write selectors that will cause the traversal of more nodes before the browser applies a style to the element.

.popover .popover-children .popover-children--active {}

.element element-item--pureVersion span:last-child {}

Removing overqualified elements improves performance by eliminating the need to match unnecessary elements and reducing the bytes used in your CSS file.

Since browsers evaluate selectors from right to left, a universal selector starts by matching every element in the document. Afterwards, it will attempt to match the next selector on the left. Since some developers enjoy the ease of universal selectors, I will not dismiss the validity of using a top level universal selector.

Writing selectors by attributes match all the elements first and then match the attribute itself. So it is redundant and relatively slower than using classes as selectors.


/* even more expensive after evaluating right to left */

These extra lines are booby traps for future developers looking at your code, and these additional lines waste bytes and CSSOM building time.

/* avoid: width, height, margin, float */

You can often write multi-line CSS rules as a single rule to save bytes.

There is no difference between 0px, 0em, and 0% or any zero-value. The browser knows what to do if you omit the unit. Save your bytes here.

Once you get into the habit of writing performant CSS, you'll be on your way to building performant web apps and websites that load in sub-seconds. If you are writing a CSS generator, following some of these rules will give you an edge.

http://calendar.perfplanet.com/2011/css-selector-performance-has-changed-for-the-better/

http://perfectionkills.com/profiling-css-for-fun-and-profit-optimization-notes/

https://benfrain.com/css-performance-revisited-selectors-bloat-expensive-styles/

http://clubmate.fi/oocss-acss-bem-smacss-what-are-they-what-should-i-use/

https://developer.mozilla.org/en-US/docs/Learn/CSS/Introduction_to_CSS/How_CSS_works

https://developers.google.com/web/fundamentals/performance/critical-rendering-path/constructing-the-object-model

https://developers.google.com/web/fundamentals/performance/critical-rendering-path/page-speed-rules-and-recommendations

https://developers.google.com/web/fundamentals/performance/critical-rendering-path/render-tree-construction

http://www.testmycss.com/#universalSelectors

https://github.com/CSSLint/csslint/wiki/Rules

A set of tactics to ensure fast CSS object model creation.

Hey! My name is Jim and I love to build websites. You can learn more about me 