How to identify IE Add-Ons such as Skype that impact Web Site Performance

I occasionally get invited to do JavaScript/AJAX Performance Workshops. Last week I spent two days with a group of dynaTrace AJAX Users that work in a performance task force group within their R&D Organization. I asked them about the reasons for this Client-Side Performance Initiative. They told me the following story:

One of our sales managers started to complain about several pages of the product we sell being too slow to demo therefore impacting his ability to pitch and sell the product. We analyzed the page in-house but couldn’t reproduce the same exact behavior. After some back and forth we identified that it was the Skype Add-On for Internet Explorer caused the performance hit on those pages that had a very large DOM with many table rows and many nested divs. This raised the awareness of client side performance and that there is much to learn about how browser work and how the generated HTML impacts JavaScript, Rendering and IE Add-Ons.

If you query for Skype Add On Performance Problem you actually get several hits on blogs that already talk about this problem: MSDN Blog or Softpedia.

Why these Add-Ons are slow?

Add-Ons like Skype have to iterate through the DOM whenever a page is loaded or modified. The time it takes to iterate the DOM depends on the size of the DOM. That explains why those Add-Ons don’t have the same web site performance impact on every page as it depends on the number of DOM elements. It is a general JavaScript/AJAX Best Practice to limit the number of DOM elements as there are many other implications with large DOM trees, e.g.: Impact on CSS Selector Performance.

How to identify slow Add-Ons?

I enabled the Skype Add-On and went to Yellow Pages searching for Dynatrace in the Boston Area. When the page is fully loaded Skype starts parsing the DOM and then modifies every phone number it finds so that I can just click on the number and call it via Skype:

Skype Add On identifies a phone number on the page and allows me to call this number
Skype Add On identifies a phone number on the page and allows me to call this number

The result page of Yellow Pages was not too big and it only contained a handful of identified telephone numbers. But still – even on this smaller page it took a noticeable amount of time from the point where the page seemed to be loaded till the phone numbers showed up. I also noticed that the page was not interactive during that time. Using Dynatrace AJAX Edition shows me what is happening on on that page from the time I entered the URL till it got modified by Skype:

High CPU Time that is not related to any JavaScript user Download Activity indicates Add On Activity
High CPU Time that is not related to any JavaScript user Download Activity indicates Add On Activity

The Timeline View shows us all network requests, javascript and rendering activity. The CPU column visualized the CPU Utilization of the browser process. What is nice to see on the screenshot above is the CPU that was consumed by the initial HTML Document Download (first two seconds on the page), JavaScript that executed (from second four to six) and the CPU that is not caused by any JavaScript or Network Downloads (from second 7 to 9). This last portion of CPU can be contributed to our Add-Ons – in this case it is mainly the Skype Add-On.

By looking at the timeline and correlating the CPU Utilization to the other browser activities we can easily tell if there is something else going on in the browser that is not directly triggered by our web site.

Any other Add-Ons that cause you problems?

Developer Tools that Add-On to the Browser are another source of problems. Usually they don’t impact performance when you are not explicitly using them – but it is definitely worth disabling them while you don’t need them. I am interested in other Add-Ons that you have identified as being problematic. Let me know by posting a comment on this blog.

Andreas Grabner has 20+ years of experience as a software developer, tester and architect and is an advocate for high-performing cloud scale applications. He is a regular contributor to the DevOps community, a frequent speaker at technology conferences and regularly publishes articles on You can follow him on Twitter: @grabnerandi