Really Aced

Hello,

Here’s a long (but hopefully interesting) post about JavaScript performance in Internet Explorer.

As I had some time over in between sprints, I started looking at the performance of our site in Internet Explorer again. The webapp runs very smoothly in Firefox, but some pages take a few seconds (!) to load in IE, due to its “JavaScript density”. In order to find out what we’ve done wrong, I decided to test changing our core JS framework from Prototype to jQuery. Although, this (alone) didn’t result in any noticeable improvements (in short: there’s been a few tests claiming that jQuery is X and Y times faster in general than Prototype in IE).

There wasn’t (and isn’t) any obvious parts of the code that would slow down the site in IE alone, so I decided to try to find the methods that were slowing it down. To do that, I needed a profiling tool. And finding one of those for usage in IE wasn’t easy (in FF you can always use Firebug’s profiling tool).
After some research, I found:

* AjaxView
* JavaScript Profiler 2.0

None of them gave me the result I wanted, as they provided little or no information on what was actually running slow (although it did show me indications of total mean times).
I knew when I started that YUI provides a Profiling tool, but my first priority was to use a standalone client to avoid having to alter my code. But with no other choices, I decided to try it out, and that was obviously a good choice. I read the docs of YUI Profiler and ProfilerViewer and tested them. Reading and setting up the profiler took about 15 minutes.

The thing about using the YUI Profiler is that you have to manually add the methods to profile, but it was an easy task and probably better/more efficient than profiling everything (as Firebug does) since the noise is heavily reduced.

After a while, it was pretty obvious which methods were running slow in IE (note that they were barely tracked in FF); some basic methods took up to 900 ms at first.

Worst methods from my first profiling iteration:

After iterating “optimizing-profiling-optimizing-profiling” for a while, I managed to reduce the load times with about 40%, without losing any real feature. It was mostly about modifying CSS selectors (i.e. removing one level in the hierarchy) and making sure some methods were only run if they really had to.

Results after optimization:

1) Removed unnecessary call
2) Moved initialization to click

Note that the counts aren’t necessarily 100% correct, as several other factors affect the load time (current memory usage etc).
But anyway, the results were massive and the load times were heavily decreased.

So to conclude:

As mentioned. it’s not always easy to know which those methods are by simply looking at the code (IE always tricks us…).
All “JavaScript dense” pages should be profiled (with YUI Profiler until a better tool is found) in order to find methods with poor performance.

More or less interesting articles/documents on the subject:

http://blogs.msdn.com/ie/archive/2007/08/23/Analyzing-Web-2.0-Applications-with-Ajax-View.aspx

http://research.microsoft.com/en-us/projects/ajaxview/ajaxviewusage-1.aspx

http://www.whitefrost.com/documents/html/technical/dhtml/monitor.html

http://www.newearthonline.co.uk/index.php?page=article&article=338&pagenum=2

http://msdn.microsoft.com/en-us/library/bb250448.aspx

http://www.ajaxperformance.com/2008/02/20/yui-profiler/

http://www.titosoftware.com/

http://blogs.msdn.com/ie/archive/2006/08/28/728654.aspx

http://blogs.msdn.com/ie/archive/2006/11/16/ie-javascript-performance-recommendations-part-2-javascript-code-inefficiencies.aspx

http://blogs.msdn.com/ie/archive/2007/01/04/ie-jscript-performance-recommendations-part-3-javascript-code-inefficiencies.aspx

http://dev.opera.com/articles/view/efficient-javascript/