{"id":26305,"date":"2016-04-06T21:01:39","date_gmt":"2016-04-06T13:01:39","guid":{"rendered":"https:\/\/www.hongkiat.com\/blog\/?p=26305"},"modified":"2022-07-15T17:06:44","modified_gmt":"2022-07-15T09:06:44","slug":"writing-better-css","status":"publish","type":"post","link":"https:\/\/www.hongkiat.com\/blog\/writing-better-css\/","title":{"rendered":"How to Write Better CSS with Performance in Mind"},"content":{"rendered":"

Editor\u2019s note: <\/strong>This article is part of our Code Optimization series<\/a>, where we take a look at how to optimize coding for better efficiency in a bid to be better coders.<\/p>\n

In today\u2019s post we will ponder over the code choices we can make in CSS for improved site performance. But, before we dive into those choices, let\u2019s first take a brief, closer look at the webpage rendering workflow<\/a> in order to focus on the <\/em>problematic (performance-wise) areas that are solvable via CSS.<\/p>\n

\"Browser<\/figure>\n

Here\u2019s the rough flow of operations performed by the browser after DOM tree creation:<\/p>\n

    \n
  1. Recalculate Style (and render tree creation). <\/strong>Browser computes the styles to be applied to the elements in the DOM tree. A render tree is later created while discarding the nodes (elements) from the DOM tree that aren\u2019t to be rendered (elements with display:none<\/code>) and those that are (pseudo-elements).<\/li>\n
  2. Layout (aka Reflow). <\/strong>Using the computed style from before, the browser calculates the position and geometry of each element on the page.<\/li>\n
  3. Repaint. <\/strong>Once the layout is mapped, pixels are drawn to the screen.<\/li>\n
  4. Composite Layers. <\/strong>During repainting, the painting might be done in different layers autonomously; those layers are then finally combined together.<\/li>\n<\/ol>\n

    Now let\u2019s continue on to what we can do in the first three stages of the operation to write better-performing CSS codes.<\/p>\n

    1. Reduce Style Calculations<\/h2>\n

    Like mentioned before, in the \"Recalculate Style\" stage the browser computes the styles to be applied to the elements. To do this, the browser first finds out all the selectors in the CSS that point to a given element node in the DOM tree. Then it goes through all the style rules in those selectors and decides which ones are to be actually applied to the element.<\/p>\n

    \"Style
    IMAGE: Aerotwist<\/a><\/figcaption><\/figure>\n

    To avoid costly style calculations, reduce complex and deeply nested selectors<\/strong> so that it\u2019s easier for the browser to figure out which element a selector is referring to. This reduces computational time.<\/p>\n

    Other ways to employ include reducing the number of style rules<\/strong> (where possible), removing unused CSS<\/strong> and avoiding redundancy & overrides<\/strong>, so that the browser doesn\u2019t have to go through the same style again and again during style calculations.<\/p>\n

    Tip:<\/strong> To reduce style calculation cost, a reduction in DOM tree size is as equally effective as the reduction of style rules.<\/p>\n

    2. Reduce Reflows<\/h2>\n

    Reflows or Layout changes in an element are very \"expensive\" processes, and they can be of an even bigger problem when the element that went through the layout changes has a significant amount of children (since Reflows cascade down the hierarchy<\/strong>).<\/p>\n

    \u201cAt Google, we test the speed of our web pages and applications in a variety of ways \u2013 and reflow is a key factor we consider when adding features to our UIs.\u201d \u2013 Google Developers<\/a><\/em><\/p>\n

    Reflows are triggered by layout changes to an element, like changes to the geometric properties such as height or font size, the addition or removal of classes to elements, window resizing, activated :hover<\/code>, DOM changes by JavaScript, etc.<\/p>\n

    Just like in style calculation, to reduce Reflows, avoid complex selectors <\/strong>and deep DOM trees<\/strong> (again, this is to prevent excessive cascading of Reflows).<\/p>\n

    If you have to change the layout styles of a component in your page, target the styles of the element that is at the lowest in the hierarchy of elements<\/strong> that the component is made of. This is so that the layout changes doesn\u2019t trigger (almost) any other Reflows.<\/p>\n

    If you\u2019re animating an element that goes through layout changes, take it out of the page flow <\/strong>by absoutely positioning it<\/strong>, since Reflow in absolutely positioned elements won\u2019t affect the rest of the elements on the page.<\/p>\n

    To summarise:<\/strong><\/p>\n