Recently I had the opportunity (or perhaps obligation) to dive into the topic of tracking down and fix a variety of unhandled DOM elements causing layout reflow on every update. Given that these reflow can be caused for multiple reason, there always seems to be a new issues. Issues, which I have not yet encountered. This causes me to end up search through Stack Overflow in an attempt to find answers. Hopefully by sharing my learning in this post, it will be able to share your time and effort in the future.
Dependent on the reference, a layout reflow can also be found under the name “layout thrashing”. To avoid any misunderstanding, we will start with a definition.
As a start let us define what I mean when I say layout reflow. All of our HTML elements resides in the DOM (Document Object Model), and acts and reacts to each others appearances dependent on a set of rules. A dependency in this case, refers to the need for “recalculation” of the one elements layout based on the change of another element’s layout.
E.g., if the element’s size, position, or content changed, it might effects its neighbour elements, if they were dependent. The list for what can cause a reflow is quit extensive, and I would therefore advise to check out “What forces layout / reflow” to keep up to date.
If a one or more elements start reacting to another elements change it will likely start cascading to other elements, and soon the entire DOM will be repainted. It is therefore relevant to monitor the containment of element dependencies and restricted the layout dependencies on elements. Especially if these elements are intended for frequent or automatic use cases.
When trying to detect or look for the source of a reflow, we have two choices within the Chrome DevTools utilities: “Performance” and “Rendering”.
Within the Chrome DevTool’s main tabs, you found find the “Perfomance” tab. The performance utility can make recordings of your web pages activities and highlight which runtime processes it is undergoing and for how long (Image 1).
If a performance recording showed a spike in rendering time, it might be due to a layout reflow. Diving deeper, if the specific rendering activity is determined to be “recalculation”, it is a reflow (Image 2).
When the reflow has been detected, it is possible to determine point of origination within the code, by setting the focus to the “recalculation” process (Image 3).
The performance utility has main other valuable features. If you would like to learn more, I would suggest checking out the official source: Analyze runtime performance.
In comparison to “performance”, the “rendering” utility is (to my knowledge) a less well-known tool. However, after discovering it, it has become a stable part of my developer toolset. Under the “More tools”-dropdown option, you will find a whole list of additional tools. One of those tools being “Rendering”.
“Paint flashing” is a feature of the rendering tool, which adds a flashing effect to any element on the web page, which has been repainted (Image 4). Activating “paint flashing” and afterwards doing a run-through of your application will quickly show if any element causes a reflow (Image 5). Visually a contained reflow, will only flash the updated element. Meanwhile an uncontained reflow will cause the entire web page to flash.
If you would like to learn more about the Rendering utility, you will be able to find more information here: Performance features reference – View painting events in realtime with Paint Flashing
Dependent on the source of the reflow, the fix might be one thing or another. Normally you should come a long way by adding the CSS property “overflow: hidden” to the element. This means that changes to the content, that would normally cause recalculation of the layout, will now instead be contained within the element.
A long list of other solutions will also be possible, but those will likely be dependent of the specific cause of reflow. The focus of this article is to highlight methods of discovering layout reflows. I hope that with the source determined, you will be able to find the solution within the references on this article or online.
Analyze runtime performance – Kayce Basques – Article
Performance features reference – View painting events in realtime with Paint Flashing – Kayce Basques – Article
Performance features reference – Kayce Basques – Article
Simplify Paint Complexity and Reduce Paint Areas – Paul Lewis – ArticleAvoid Large, Complex Layouts and Layout Thrashing – Paul Lewis – Article
My name is Daniel H. Jacobsen and I’m a dedicated and highly motivated software developer with a masters engineering degree within the field of ICT.
I have through many years of constantly learning and adapting to new challenges, gained a well-rounded understanding of what it takes to stay up to date with new technologies, tools and utilities.
The purpose of this blog is to share both my learnings and knowledge with other likeminded developers as well as illustrating how these topics can be taught in a different and alternative manner.
If you like the idea of that, I would encourage you to sign up for the newsletter.