Avoid Non-composited Animations

Non-composited animation is related to main thread work that we had covered in a previous section. If your page has any animation that can be affected, or triggered, by JavaScript or CSS code, and it causes the browser to go through the rendering process, or rendering pipeline, again, this is referred to as non-composited animation. From a user perspective, this causes all sorts of different issues, like layout shifts and impact on the overall quality of the animation.

As we mentioned previously, browsers must go through their own rendering pipeline process to render your web page. Altogether, there are six steps. Each of these steps is dependent on the previous step. The steps are as follows:

• • Download and parse all HTML, CSS, and JavaScript
  • JavaScript execution
  • Determine web page styles
  • Determine the page layout
  • Paint the element pixels
  • Composite layers to screen

The first five steps of the rendering pipeline are part of the main thread work that we referred to earlier. This is where the bulk of the work is done. The last step, composite, is carried out on its own thread. So, the more main-thread work the browser must process, the longer it is going to take to load the page. Secondly, and we talked about cumulative layout shifts (CLS) earlier in this guide, any time the rendering pipeline process has to re-start, the more users will experience page content layout shifts. The best way to avoid non-composited animations is to change the properties that affect composited animations, such as transform and opacity, and to make sure that any CSS elements that affect layout, such as width, height, padding, position, border, etc., are reviewed to ensure that they do not trigger the page re-painting process.