Every time I meet up with web developers, either through a customer engagement or when I am giving a presentation about web performance optimization, I ask this question: Who is using Firefox and who is using Internet Explorer as the main browser? The answer is easy to guess. I hardly ever get any hands raised for Internet Explorer. And honestly – I don’t blame them as there are so many great tools on Firefox such as Firebug or YSlow that are great to profile and debug your web application. The problem though is that a big majority of their end-users are going to use Internet Explorer (46% market share in Nov 2010) and might not be happy with their end-user-experience. Check out the following articles for more details on bad performing web sites in Internet Explorer: Top 10 Client-Side Performance Problems in Web 2.0.

As recently announced on our blog there is a solution to that problem – dynaTrace AJAX Edition is extending its browser support to Firefox. This not only allows you to profile, debug and trace your web site’s performance – the great thing is that it is a single tool that does this for the two major browsers allowing you to compare side-by-side how well your code works on both browsers and gives you an idea of where to optimize.

Compare a Twitter Search in FF and IE
I decided to look at a Twitter scenario where I am searching for a keyword. To keep it simple I just use the URL that already contains the search keyword – in my case this is the following URL: http://twitter.com/#search?q=dynatrace. I record this URL using dynaTrace AJAX with both browsers (running IE 8 in Compatibility Mode). Before I do that I make sure that the browser cache is cleared as I am not only interested in JavaScript but also in Network Requests and how the download may affect JavaScript execution. After recording I have two sessions in dynaTrace AJAX Edition:

Two dynaTrace AJAX Sessions - one for each browser

Step 1: Performance Report
The first thing I do is open the Performance Report that shows the analysis of the recorded data based on our Web Performance Optimization Best Practices. Doing this for both sessions gives me a quick overview, including the most interesting key performance indicators:

Comparing the Performance of the same Twitter URL executed by Firefox and Internet Explorer

There are several interesting things here: Firefox was slower with the onLoad time but faster with the Fully Loaded Time. It also requested 5 fewer resources than Internet Explorer. Now – we have to be careful with timings here as this is just a single test sample. It would be better to run multiple tests on each browser and look at average values across tests to rule out volatile results. But it is an interesting observation. We have to ignore the First Impression Time for now as the version of Firefox I use doesn’t yet support true Rendering Time capturing (coming soon).

Step 2: Network Differences
Let’s start with the “hard facts”: It seems that there are fewer Network Requests for Firefox than for IE. Looking at the Network Resources we see one interesting difference right from the beginning. The URL that I used contains a Hash-Tag (http://twitter.com/#search?q=dynatrace). The browser fetches the URL (excluding the hash tag – http://twitter.com). Inline JavaScript in the returned HTML parses the actual URL and changes the location to http://twitter.com/search?q=dynatrace which causes the browser to request this URL. Let’s look at those first requests in both IE and FF:

IE Starts requesting embedded resources before JavaScript changes window.location

We can see that one of the Network Differences is the first embedded CSS File that IE starts to download. It starts downloading it but doesn’t finish as an inline JavaScript function changes the window.location and forces an abort of all other downloads. Firefox seems to show a different behavior where it does not start downloading embedded resources before the inline JS gets executed. This, however, could also just be timing related. In any case, a good practice here would be to place the inline JavaScript that forces a redirect to a different URL to the very top. This will eliminate unnecessary requests. The Timeline View of this part shows us what happens in IE and in FF:

Firefox executes the two inline JS blocks before starting to download any other resources

The other difference in network requests were two extra tweets that were not displayed in Firefox – probably because I executed the query at a slightly different time and these two older tweets didn’t make it in the default results list.

Step 3: Timeline of complete Page Load
The Timeline is one of my favorite views in dynaTrace AJAX Edition. It shows me Network, JavaScript, Rendering and events such as onLoad, XHR’s or User Interaction Events all together organized by time. The current version that I am using does not yet implement all the features (remember – we are still pre-Beta) – however – comparing the Timeline of both browsers allows me to see where the major differences are:

Shorter loading times and more downloads in parallel lead to faster onLoad Time in Firefox

As I said in the beginning – we should do multiple test runs in order to rule out outliers. But still – what we can see here is that Firefox is faster with downloading all the network resources. This is mainly explained due to the fact that Firefox uses more physical connections per domain to download resources. What is really interesting is the big JavaScript Execution block. I would have assumed that Firefox is faster in JavaScript execution – in fact it turned out that IE was slightly faster. Hovering with the mouse over the big red block shows 1.136s for IE and 1.317 for FF. Overall there is still a little more JS Execution Time in IE as the script blocks at the beginning of the page take longer. But – let’s have a closer look at the JavaScript execution.

Step 4: Compare JavaScript Execution
Let’s start by double-clicking on the big red block. It is the JavaScript execution of the returned search result. The script contains a call to processHomepageSearch with a string parameter that contains the HTML that should be displayed in the search result area. When we look at the two PurePath’s in a Side-by-Side Comparison we see something that I didn’t expect:

DOM Object lookups (finds) are faster in IE where DOM Manipulations are faster in FF

The real surprise from my perspective – based on all the blogs I wrote about CSS Lookup Performance in IE – is that Firefox is slightly slower in iterating through the DOM to lookup those DOM elements, e.g.: “.status-body a,.vcard a”. What is less surprising is that renderResultsFromSummize is faster in Firefox. If we take a deeper look into that method we see that it actually modifies the DOM by creating all those DOM objects as passed in the string parameter through jQuery helper methods. Especially changing innerHTML seems to be much faster in Firefox than IE. There are a total of 98 innerHtml changes in my example taking 87ms on IE and only 45ms in FF.

Another way to look at JavaScript is to look at the Hotspot View which represents an aggregated view on all JavaScript, DOM and Rendering traces. The Hotspot View allows us to answer different types of questions such as which methods were invoked how often (sort by Invocation), which methods have a long Execution Time (sort by Exec Avg.) or which methods have a long Total Time (sort by Total Avg):

Side-by-Side JavaScript Profiling differences between Firefox and Internet Explorer

Conclusion
As we are getting closer to “Feature Complete” with the dynaTrace AJAX Edition for Firefox we will post more findings about performance-related Firefox topics. Similar to what we did for Internet Explorer, we plan to look at different real-world sites and highlight which Best Practices to follow – similar to what we did with Fifa WorldCup, The Masters or Frankfurt Airport. We will also look at Best Practices on frameworks such as jQuery, Prototype, … If you have any performance-related topics that interest you – whether it is pure Firefox or how things are different between FF and IE – then let us know.

Related reading:

1. Sneak Peak on Firefox support with dynaTrace We have received lots of great feedback on our deep...
2. Garbage Collection in IE7 heavily impacted by number of JavaScript objects and string sizes After my recent presentation at TSSJS – Performance Anti-Patterns in...
3. Week 8 – Challenges in Tracing JavaScript Performance by Example In an earlier post I already discussed several approaches towards...
4. How to use your Selenium Tests for automated JavaScript/AJAX Performance Analysis With more than 3 million downloads, Selenium is the world’s...
5. Antivirus Add-On for IE to cause 5 times slower page load times The dynaTrace AJAX Community has been really active lately –...