Forced reflow while executing javascript code#
The difference is that code snippet 3 does that in the end of the CRP cycle, and then it uses the layout cache instead of recalculating it during the CRP cycle.įigure 5 shows that we have managed to avoid forced layout by deferring the emitEvent call and the measurement to after the layout phase was complete. In the file:Ĭode snippet 3: The async solution to forced reflowīoth code snippet 3 and code snippet 1 send the measurement after the DOM changes have been made. The reflow in Figure 3 happens because a simple line that was added to the code. You can see that the style and layout parts start after the javascript finished running. Let’s compare it to the CRP recording of a reflow-free code: Figure 4: A “healthy” CRP recording as shown in a former article You can see that the style and layout parts (the purple part) are now inside the javascript part – causing it to run longer. Purple part under the yellow javascript part is the reflow. Here’s the result of the sorting scenario described above: Figure 3: Layout reflow monitoring result. It then allows you to sort the users by their ID or name. Query the server (just use the input field at the top)Ī short TL DC (too long, didn’t clone) – the app queries a list of users from a server.In this exercise you will see an example for Forced reflow while executing JavaScript. element.style('height', 500) Ĭonsole.log(element.style('height')) Exercise – Create a Forced Reflow For instance, in the code below, we change the height of an element and then query its height.
The reflow happens when during Javascript we mutate the DOM and then measure it. If you measure the size or position of an element at this stage, the browser needs to recalculate the whole DOM in order to give you the real answer. Changing the DOM is called: Mutate.Īfter you are changing the DOM, the browser flags its layout cache as invalid and schedules a recalculation. Appending elements, changing height/width or position of elements etc. Now, let’s assume you are changing the DOM. The browser knows how the DOM looks like, and if it knows it didn’t change, it just gets the correct value from the layout cache (created in the former calculation). When you query the DOM for size or position, the result is usually taken from former calculations. The rest of the flow runs then.īesides the fact we might run costly style and layout calculations twice – our javascript now takes much longer to run. The calculations were done, and the Javascript continued until it finished. The Javascript code caused the browser to initiate style and layout calculations during its run. That means that we force a later stage (layout) into our javascript.Ī reflow looks more like this: Figure 2: The CRP diagram for a reflowįigure 2 illustrates a reflow. In a nutshell, the regular flow of the code in the browser is this: Figure 1: The healthy CRP diagramįorced Reflow is a disturbance in the force… sorry… in the flow. I wrote about the Critical Rendering Path (CRP) in a former article. Sometimes, something in the cycle can go wrong.
It does it by running the same rendering cycle again and again. We give it JS, HTML and CSS – and they are translated into visual wonders. With this knowledge, I was able to improve performance of an app in my workplace by 75%. It happens when a measurement of the DOM happens after a DOM mutation. Force reflow (or Layout Reflow) is a major performance bottleneck.
0 kommentar(er)
