Share This:

Have you ever wondered why modern browsers have such a short shelf life? As soon as you've finished your testing cycle and all your applications have finally been approved on one browser, the next one comes out and you have to start all over again. The browser you’re on is suddenly considered outdated and everyone is trying to convince that you have to upgrade.


It wasn’t always like that. Internet Explorer 6 was first released in 2001 and was still being used ten years later. It wasn’t until 2006 that version 7 was finally released, but it was perfectly acceptable to continue using version 6. Firefox used to update its browser more frequently, but it still came down to one major upgrade every two years or so. In 2004 Firefox was still in version 1, seven years later it had moved up to version 4. Two years later, fast-forward to version 21.


So, why is all this happening? By the time Internet Explorer 6 was released, the proliferation of new web technologies had stabilised, but in the last few years things have really started speeding up again. CSS, for example, has gone through some major changes in recent versions, HTML DOM has improved a lot, and then there’s JavaScript.


Mid-Tier relies very heavily on JavaScript; it’s what makes it tick. We use it to execute all those Active Links, we use it for reporting, and we use it to communicate between your browser and the web server. It’s what makes the application interactive – without JavaScript Mid-Tier wouldn’t work. There are many benefits to using JavaScript and Mid-Tier takes every advantage of them.


The downside of this approach is that we depend on the browser to execute all this code. Browsers are 3rd party products so we are limited in our control over the execution. We can change our code to avoid known problems, and even write different code for different browsers to ensure it all works fine, but the one thing we don’t have any control over is the speed of JavaScript execution. It’s easy to underestimate the amount of JavaScript code we use, but as Remedy is designed to be as dynamic as possible there’s a lot of code that we ask the browser to execute. In order to get the best performance you need to use a browser with a fast JavaScript engine.


That’s where we’re really at the mercy of the browser, and some browsers are better at executing JavaScript than others.  These are the results of WebKit’s SunSpider benchmark:



Source: The New JavaScript Engine in Internet Explorer 9 - IEBlog - Site Home - MSDN Blogs


The graph is a bit outdated, but it illustrates the point. What we’re looking at here is the speed of the JavaScript engine in general – we measure how long it takes to process the same JavaScript. Browsers like Firefox and Chrome are highly optimised for JavaScript performance, but you can see that Microsoft significantly improved its execution time.


So what is it about IE8 that’s causing a problem here? The answer is simple: the JavaScript engine is outdated and didn’t evolve to keep up with the requirement for fast, responsive applications. Unlike for example Firefox, Internet Explorer does not automatically upgrade (other than patches) so when Microsoft finally acknowledged the performance problem they went on to improve in IE 9, IE 8 was left behind. This is what Microsoft writes on the subject:


IE8, like other versions of IE before it, included a script interpreter for running JavaScript. Pure interpreters are usually adequate for traditional web pages with limited amounts of script, and we did a lot of work to improve performance of these sites in Internet Explorer 8, both in script as well as across the browser.


With IE9, we decided that we needed a better approach to building a script engine for the present and future demands of the Web. Clearly, the new engine had to be able to run traditional pages well. But the engine also needed to perform well on Web applications of today and the HTML5 application of tomorrow, as well as keep up with changes in the Web and in the devices used to browse it.


Source: The New JavaScript Engine in Internet Explorer 9 - IEBlog - Site Home - MSDN Blogs


BMC performed its own tests and came to similar conclusions. When we define certain transactions users would perform on a daily basis you can clearly see browsers with a faster JavaScript engine perform better than those with slower engines:




Source: Response times - BMC Remedy OnDemand 2013.01 - BMC Documentation


Let’s have a look at two tests to get a better understanding of why the JavaScript engine plays such a big role in determining the performance of Mid-Tier. Say you have 2000 records (out of 10,000 records) in your result list for Incident Management and you click through this, we execute JavaScript code every time you click on a new record:


Total time (in sec)
IE94 - 6
Firefox4 - 6


We still have to wait for the server to return the data, but most of the time is spent waiting for JavaScript to be executed. If you check with a client debugger what causes the delay, you can see IE8 spends far more time running through the same code. For example JavaScript’s clear function took 1.4 seconds on IE9, but 41 seconds on IE8. When we scroll through such large result lists, the code has to keep track of the records in the result list, which is something IE8 struggles with.


For our second test, let’s have a look at the communication between the browser and the server. The browser uses AJAX to communicate with the web server, so, again, it uses JavaScript for all HTTP requests. Some parts of the product send out a lot of HTTP calls so the JavaScript engine needs to be up to scratch. This is evident if you use SRM – you might, for example, be familiar with the Activity Details tab which contains a history of the various activities that happened with a certain request. For each activity we load, we send out a separate HTTP call to the Mid-Tier server, so the more activities you have, the more calls go out. Part of the delay is, of course, waiting for the server and the network, but every call is generated via JavaScript and all the answers contain pieces of JavaScript as well. This is the result of a typical HTTP request:


HTTP/1.0 200 OK


this.result={n:1,f:[{t:4,v:"Test Value"},{ts:1373975524}]};;if(getCurWFC_NS(this.windowID)!=null) getCurWFC_NS(this.windowID).status([]);


Say I have 15 activities, I’d ask the browser to execute these pieces of code 15 times on top of actually getting those calls out (which also is done via JavaScript). They’re fairly small, so I’m hardly overloading the browser, but if your browser isn’t the best at executing JavaScript code, you will see a noticeable difference in performance. For example, this is the result of a test with IE8, IE9 and Firefox with 24 different activities:


Total time (in sec)Time spent on server (in sec)


The time spent on the server is about the same, but it’s the JavaScript execution time that makes the difference. You can clearly see that it takes IE8 a lot longer than, for example, Firefox. Twenty-four activities is quite a lot, but it demonstrates that the more the browser struggles to execute the code, the slower it gets.


So is it just the JavaScript engine that causes performance problems? It’s certainly the main culprit, but there are other problems with IE8 which are particularly evident in version 8.1.  Mid-Tier needs to perform a great deal of rendering of the various pages, and relies on the browser’s rendering capabilities. As Mid-Tier’s forms are so complex, you’ll notice a performance difference if your browser has fast rendering capabilities. In all fairness, IE8 isn’t too bad in this area, but causing a problem when changed our approach in Mid-Tier 8.


As a web application, we need to ensure we stay compatible with the various browsers we support. Up to version 7.6.04, we still used browser specific CSS/HTML code. In order to ensure this was still running on all browsers we applied quirks mode. In version 8.0 we moved HTML coding to strict mode (or standards mode as it’s also known), in order to comply with the current W3C and EITF standards. As this eradicates any dependencies on old, unsupported, browser-specific code, Mid-Tier is ready for broader supportability.


The downside of this approach was IE’s implementation of strict mode in IE8. In this mode the browser was struggling to render certain page elements, resulting in noticeably poor performance. We’ve worked closely with Microsoft to optimise our code, but as the limitation is on the browser side and we can’t go back to supporting both modes, we are constrained in what we can do. Microsoft has improved its implementation in IE9, but unfortunately IE8 is still affected.


So what to do next? Upgrading your web browser should be the first thing you do to improve your Mid-Tier performance; the web is constantly evolving and Mid-Tier will evolve with it. BMC optimises the code for the various browsers and browser versions we support, but if you want to avoid performance problems resulting from using an older version, consider upgrading. Always make sure to check BMC’s compatibility matrix before you upgrade.


So do Mid-Tier performance problems always come down to JavaScript execution and page rendering? No, there’s more to it than that. You might be on the latest browser version and have tweaked your browser as much as can, but if your server is struggling under the weight, performance will still be a problem. After all, Mid-Tier is not a static web application, we also depend very heavily on the server to process our various calls. Your JavaScript might execute great, but if you’re waiting for your Mid-Tier server to return the data it will still slow down. How can you improve that? Well, we’ll look at the Mid-Tier server performance next time.


Right, that’s all for now. Until next time,



Further reading:


  1. Microsoft’s blog post on IE9 improvements:
  2. BMC’s benchmark tests with various browsers:
  3. General suggestions to optimise Internet Explorer performance: