Understanding Internet Explorer Rendering Behaviour

December 12, 2009

Rendering is one of the key influencers of the perceived performance in web applications. In order to optimize the rendering behaviour of a web application you have to first understand how rendering works in the browser. Mozilla provides a very good documentation on how rendering works in Firefox. Although we are talking here about Internet Explorer, the basics are the same. The rendering task is responsible for transforming the logical representation of a document – the DOM – into a graphical representation. This process consists of two steps:

Calculating the layout based on DOM elements. This step is referred to as Calculating Layout in Dynatrace AJAX Edition. Mozilla refers to it as Reflow. However they admit that “…perhaps should have been called layout”.

Drawing or painting of the HTML page

The normal flow when a document gets loaded is to incrementally build up a DOM tree, perform layout calculations of the elements and finally draw the document. Internet Explorer does this by parsing the HTML and CSS code, during which it schedules layout tasks. After the document (or part thereof) has been parsed, it sends itself a message that the scheduled layout tasks should be performed. When this message is handled by the process’ message handling mechanisms, Internet Explorer iterates the queued layout tasks and performs the necessary calculations. It then invalidates regions of the window that need to be redrawn and the Windows graphics system sends the window a message of type WM_PAINT which tells the window to repaint itself [3]. Note that the document gets repainted even if nothing visible changed, for example if the dimensions of an element with the style “display: none” changed, Internet Explorer will still redraw the entire visible portion of the document. The figure below shows a schematic drawing of the Internet Explorer rendering process.

Steps in Internet Explorer Rendering and Layout

Understanding the Layouting Process

In order to illustrate how rendering works I have chosen a simple real world example. I am using two div elements. When I click a button the height of the first element will be changed. The source code of the page is as follows:

We simply create two div elements lower and upper and define a button with a click handler which changes the height of the first div. Below we see a trace of a button click in Dynatrace AJAX Edition which shows the execution of the button click handler (1) including the scheduling of the rendering task. The next path then shows the actual rendering task (2).

Rendering after changing width of a div

This also has some implications on performance analysis. If we would just measure the JavaScript execution time we would miss all rendering information. Consequently plain JavaScript instrumentation based performance analaysis cannot measure end user performance. Additionally this information is highly valuable in automated testing. When measuring rendering times during automated tests we can also detect regressions in end user performance.

Rendering triggered by Property Read Access

A behaviour which many people are not aware of is rendering caused by property access. Let us modify the sample above as follows:

We now access the height property of the lower div after the upper div’s height was modified. The difference – as we see below – is that rendering is now performed immediately when the property is accessed.

Immediate layout calculation due to property access

Why does this happen, especially as the property change on the upper div element has no effect on the lower div element? When the height property of the lower div element is accessed Internet Explorer realizes that there is a scheduled layouting task. As this task might – and most likely will – change layout properties of other elements it is performed before layouting-related information is returned by the DOM call.

Analysing Rendering Problems

Analyzing rendering problem can be quite tough. I will explain how to use Dynatrace AJAX Edition based on real world sample. The starting point for Rendering analysis is the HotSpot View. Here we see which methods consume most of the time. In many cases this will be Rendering(Drawing). Don’t be scared this is quite normal and only means that most time when the browser is actively working is used for drawing. However if – as in the case below – most of the time is spent for Rendering (Calculating …). This is a sign that obviously a high number of layouting tasks are performed. In the sample below we see that layout calculation is by far the top performance Hot Spot.

Layouting as performance hot spot

In order to find out more details we look at the backtrace and see that these layouting tasks are called within a function which performs massive DOM property access. In the source pane we see also see the source code where the sroll properties are accessed.

Property access forces rendering

Conclusion

Rendering – or better layouting – can easily become a major performance contributor in web applications. The key facts about rendering are:

Rendering is performed asychronously in the browser

Rendering is performed if elements in the DOM are modified

Rendering is also performend if layout relevant properties of the DOM are accessed

Credits

Special thanks go to Günther Gsenger of the Dynatrace AJAX Edition engineering team who contributed to this article.

Alois is Chief Technology Strategist of Dynatrace. He is fanatic about monitoring, DevOps and application performance. He spent most of his professional career in building monitoring tools and speeding up applications. He is a regular conference speaker, blogger, book author and Sushi maniac.