From time to time I access my work emails through Outlook Web Access (OWA) – which works really great on all browsers I run on my laptop (IE, FF, Chrome). Guessing that Microsoft probably optimized OWA for its own browser I thought that I will definitely find JavaScript code that doesn’t execute that well on Firefox as compared to Internet Explorer. From an end users perspective there seems to be no noticeable performance difference – but – using dynaTrace Ajax Edition (also check out the Video Tutorials) I found a very interesting JavaScript method that shows a big performance difference when iterating over DOM elements.

Allow Multiple DOM Elements with same ID? That is Not a Good Practice!

I recorded the same sequence of actions on both Internet Explorer 8 and Firefox 3.6. This includes logging on, selecting an email folder, clicking through multiple emails, selecting the Unread Mail Search Folder and then logging out. The following screenshot shows the Timeline Tab (YouTub Tutorial) of the Performance Report including all my activities while I was logged on to Outlook Web Access.

Outlook Web Access Timeline showing all browser activities when clicking through the folders
Outlook Web Access Timeline showing all browser activities when clicking through the folders

Instead of comparing the individual mouse and keyboard event handlers I opened the Hotspot View (YouTub Tutorial) to identify the slowest JavaScript methods. If you use dynaTrace just drill into the HotSpot view from the selected URL in your Performance Report (YouTub Tutorial). There was one method with a slow Execution Time. This is the pure method execution time excluding times of child method calls. The method in question is called getDescendantById. It returns the DOM element identified by it’s id that is a descendant of current DOM Element. If you look at the following screenshot we see the same method call returning no value in both browsers – meaning that the element that we are looking for (“divReplaceFolderId”) is not on that page. It’s interesting to see that the method executes in 0.47ms on Internet Explorer but takes 12.39ms on Firefox. A closer look at the method implementation makes me wonder what the developer tries to accomplish with this method:

Special implementation for non IE Browsers to get elements by ID
Special implementation for non IE Browsers to get elements by ID

If I understand the intention of this method correctly it should return THE UNIQUE element identified by its id. Seems though that IE allows having multiple elements with the same ID on a single page. That’s why the method implements the workaround by using getElementsByTagName and then accessing the returned element array by ID. In case there are more elements with the same ID the method returns the first element. In case no element was found and we are not running on IE the implementation iterates through ALL DOM elements and returns the first element that matches the ID. Looks like an odd implementation for me with the result that on NON IE browsers we have to iterate through this loop that will probably never return any element anyway. Here is some pseude-code on how I would implement this – happy to get your input on this:

var elem = document.getElementById(d);
if(elem != null) {
  // check if this element is a descendant of our current element
  var checkNode = elem.parentNode;
  while(checkNode != null && checkNode != this._get_DomNode()) checkNode = checkNode.parentNode;
  if(checkNode == null) elem = null; // not a descendant
return elem;

This code works on both IE and FF – even if there would duplicated elements with the same ID which we should definitely avoid.

Firefox faster in loading Media Player?

I continued exploring the sessions I recorded on both IE and FF. Interesting enough I found a method that initializes a Media Player JavaScript library. Check out the following image. It shows the difference in execution time for both IE and FF. This time Firefox is much faster – at least at first peek:

It appears like initializing Media Player Library is much faster in Firefox
It appears like initializing Media Player Library is much faster in Firefox

The time difference here is very significant – 358ms compared to 0.08ms. When we look at the actual execution trace of both browsers we however see that IE is executing the if(b.controls) control branch whereas Firefox does not. This tells me that I haven’t installed the Media Player Plugin on Firefox:

Actual JavaScript trace comparison between Internet Explorer and Firefox
Actual JavaScript trace comparison between Internet Explorer and Firefox

Lesson learned here is that we always have to look at the actual PurePath (YouTube Tutorial) as we can only compare performance when both browsers executed the same thing.


Before writing this blog I hoped to find JavaScript performance problem patterns in Firefox. Similar to IE related problem patterns I blogged about in the past, such as Top 10 Client-Side Performance Problems. Instead of finding real JavaScript performance patterns it seems I keep finding code that has only been “optimized” for IE but was not really tested, updated or optimized for Firefox. Similar to my blog Slow Page Load Time in Firefox caused by older versions of YUI, jQuery I consider the findings in this blog going into the same directions. Microsoft implements it’s JavaScript code to deal with an IE specific situation (allowing multiple elements with the same ID) but haven’t really implemented the workaround to work efficient enough in other browsers. By the way – comparing method JavaScript code executions as I did here with the free dynaTrace Ajax Edition are easier and can be automated using the dynaTrace Premium Ajax Extensions.

If you have any similar findings or actual Firefox JavaScript Performance Problem Patterns let me know – would be happy to blog about it.