Alois Reitbauer About the Author

Understanding Internet Explorer Rendering Behaviour

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.

rendering

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:

<html>
<head>
<script src=”./jquery.js” >
</script>
<script type=”text/javascript”>
function testRendering(){
// askforWidth();
$(“#upper”).height(“400px”);
askforHeight();
}
function askforHeight () {
$(“#lower”).height();
}
$(function(){
$(“#checkRendering”).click(function(){testRendering();});
});
</script>
<title>Rendering sample</title>
</head>
<body style=”height:100%;”>
<button id=”checkRendering”>Change layout</button>
<div id=”upper” style=”overflow:auto;background-color:#81BEF7;width:200px;height;200px;”>
</div>
<div id=”lower” style=”overflow:auto;background-color:#888888;width:200px;height:100%”>
</div>
</body>
</html>
<html>
  <head>
  <script src="./jquery.js" >
  </script>
  <script type="text/javascript">
    function testRendering(){
      $("#upper").height("400px");
   }
   $(function(){
     $("#checkRendering").click(function(){testRendering();});
   });
   </script>
  <title>Rendering sample</title>
  </head>
  <body style="height:100%;">
<button id="checkRendering">Change layout</button>
  <div id="upper" style="overflow:auto;background-color:#81BEF7;width:200px;height;200px;">
  </div>
  <div id="lower" style="overflow:auto;background-color:#888888;width:200px;height:100%">
  </div>
  </body>
</html>

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

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:

function testRendering(){

  $("#upper").height("400px");

  askforHeight();

}

function askforHeight () {

  $("#lower").height();  

}

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

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

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

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.

Comments

  1. Thanks for the this great tool and tutorial.

  2. Internet Explorer 7 contains a number of improvements to cascading style sheet (CSS) parsing and rendering over IE6. These improvements are aimed at improving the consistency of how Internet Explorer interprets cascading style sheets as recommended by the W3C in order that developers have a reliable set of functionality on which to rely. In some cases a few of these changes may have the effect of making existing content render in ways that are not compatible with IE6.

  3. Great post! Thanks

  4. mudit sharma says:

    awesome article.. was very helpful

  5. Enlightening! Thanks for time

  6. nice tips and an insight view , thanks

  7. i want to express my deep gratitude great tips thank you , greeting from houses for rent in florida

  8. i what to know how i can find out css from #47 ?
    In my project i am see lot rendering and it say #number . Please help me

  9. ” 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.”

    Does that mean that layouting blocks javascript execution if this subsequent javascript accesses layout relevant DOM information ? or any DOM access ?

    Can I visualize this blocking behaviour using dynatrace ?

  10. Olivv,

    you are right, accessing layouting information will “block” JavaScript execution. The figure “Immediate layout calculation due to property access” shows how this looks in dynaTrace.

    Additionally you get the Total Time of a JavaScript execution as well as the JavaScript time. The difference shows how much other factors where involved.

  11. Esteve Camps says:

    Thanks a lot for this tutorial and tool, and thanks in advance for Firefox support.

  12. Anonymous says:

    Rather actually! Additionally you get the Total Time of a JavaScript execution as well as the JavaScript time. The difference shows how much other factors where involved.

  13. Does that mean that layouting blocks javascript execution if this subsequent javascript accesses layout relevant DOM information ? or any DOM access ? Can I visualize this blocking behaviour using dynatrace ?

Comments

*


seven − 6 =