Siebel IP16 – Browser Battle Benchmark

So – how does rendering performance has evolved with Innovation Pack 2016? I have been asked that question a number of times in the recent past. So, I put Innovation Pack 2016 on the rack, measuring Open UI’s response time per usual benchmark approach.

Again, four views with increasing complexity are used. Where really, the complexity of View 4 is ludicrous and primarily meant for stress-testing. In the past IE11 showed a non-linear pattern, that is why I included that impossible complex view.

Those ‘non-linear days’ are over due to largely IE11 specific framework enhancements included in IP15.3/14.9 back in September 2015. Based on my measurements we could say, that Innovation Pack 2016 does a slightly better job compared to IP15.3/14.9. Nothing spectacular. Call it stable.

meta-chart– Jeroen


Firefox To Drop NPAPI Support Late 2016

Firefox-DisabledJavaPluginThe word is out from the Mozilla blog: Firefox will de-support NPAPI Plug-ins late 2016. Mozilla following the same path as Google but with a remaining grace period of about 15 months. Although Mozilla announced it will still support Flash, Java will be a dead-end in the browser. Even though Siebel Open UI does not heavily rely on Java there are some bits and pieces which do. The most important obvious one would be the ‘inline editing’ mode of Siebel attachments. And then obviously there are customers who have resorted to a Java applet for some kind of desktop integration, replacing the traditional HI / ActiveX Web Client Automation Server capabilities to attach to a Siebel web session.

Good to know, with Innovation Pack 2016 there is a planned feature to replace current Java applet based functionality with an open Web Socket framework. Check the Innovation Pack 2016 Statement of Direction to get more details. The Web Socket framework will be open and published as API for customers to take advantage of.

– Jeroen

Siebel OUI: Windows 10 + Edge – Ultimate Replacement For IE?

The team at have produced a nice & updated comparison between the Edge browser which comes with Windows 10 and the usual suspects, Internet Explorer, Chrome and Firefox. Using the most common benchmarks. While I personally have little trust in Sunspider for obvious reasons from the past, apparently Edge performs particularly well according to Octane 2.0 too.


It will definitely take a while before enterprise customers will move to Windows 10. The good thing is that Windows 10 will ship with Internet Explorer as well as the Edge browser.

Although Edge is brand-new, according to the HTML5Test it is still quite a bit behind on the competition. So less innovation than expected? This requires digging into a bit deeper at a later moment.

Anyways, eager to upgrade my Windows 8.1 laptop to 10 in the coming days 🙂

– Jeroen

Siebel IP14 – PS4 Has Some Performance Tricks Up Its Sleeve

A few posts back I reported about Microsoft to release a performance fix for Internet Explorer 11. Tonight I completed my initial tests with the Siebel Innovation Pack 2014 Patch set 4 which Oracle released a couple of weeks ago. The Patch Set 4 release notes make note of two particular bugs which should improve OpenUI view rendering performance. So I picked up the glove and executed my usual set of performance review scenarios. I compared Patch Set 2 against Patch Set 4, for the usual set of browsers. I ran each test three times to cancel out any measurements which could have a (too) high standard deviation. The cool thing is that the performance measurement framework does all the heavy lifting for you. Duncan discusses this simple but very effective framework in the Open UI Developer’s Handbook too.


Bottom line? All browsers benefit from the Patch Set 4. IE11 benefits most. But still IE sits all alone silent in corner. Internet Explorer – despite the performance hot fix being applied – remains no competition for Chrome and Firefox.

IP14PS4PerfCompAgain Chrome outperforms all, with significant improvements. These improvements alone should make you to consider Patch Set 4 strongly.

– Jeroen

Dromaeo benchmarking – IE11, FF R31, Chrome R37 and Canary

Besides Google’s Octane 2 there is another extensive benchmarking framework: Dromaeo.

I took it to the test for the usual suspects.

The good thing about Dromaeo is that it has dedicated tests for jQuery, very useful with OpenUI in mind 🙂

And the results are… I ran a number of tests on my good-old i5-2520M@2.5Ghz. I ensured while running the test the machine was idle.

DromaeoFrameworks DromaeoCoreDOM DromaeoJslib

The tables list the number of runs/second for the different test dimension. From those I calculated the performance factors. So “Chrome vs. IE” has a performance factor 2,9 for the “DOM Attribute (Prototype)” dimension. So Chrome R37 is 2,9x faster than IE11 for this particular characteristic.

It is clear that IE11 overall is being surpassed by its rivals. Especially when looking at the relevant dimensions for Siebel Open UI (jQuery) Chrome is the overall winner. For jQuery DOM Query/selector operations Firefox and Chrome end up ex-aequo. More general the jQuery framework is better tailored for Chrome. The more all-purpose DOM operations are best tailored for Firefox (these entail direct DOM operation without using any framework).

On generic DOM traversal IE11 is tailing its rivals.

A closer view on Siebel OpenUI performance, the Firefox – IE11 battle

In a recent previous post I already concluded that IE11 is not an ideal browser for Open UI. Which obviously is shame because still the most widely used browsers within organizations. In private life though people tend to use different browsers. But even though the decline for IE is ongoing it will take time before IE is replaced in workplace environments.


Organizations tend to move towards Firefox rather than Chrome. Most likely because Chrome being a Google product, too risky? Firefox as Open source is assumed a safer bet. But this goes at a very slow pace. We should not expect that to change dramatically over the coming years.

So, we have to deal with IE. That is why I created in Siebel OUI as couple of “test” views. Large views which have increasingly more applets and controls. These views are build on top of a VBC in order to cancel out any false-positives from the test results (e.g. to measure only rendering, not queries and fetching).

Taken for granted that I created huge views which you will never (?) see in a typical Siebel environment. But I wanted to take a somewhat scientific approach here to find a possible pattern. View 1 and 2 could be considered still realistic in terms of number of controls in certain customer scenarios – though 2 could be considered pretty outrageous.

  • View 1 (indicative: 40 controls in total)
    • One Form applet with 20 controls
    • One List applet with 20 list controls
  • View 2 (indicative: 240 controls in total)
    • One Form applet with 20 controls
    • One Form applet with 100 controls
    • One List applet with 20 list controls
    • One List applet with 100 list controls
  • View 3 (indicative: 440 controls in total)
    • One Form applet with 20 controls
    • Two Form applet with 100 controls
    • One List applet with 20 list controls
    • Two List applet with 100 list controls
  • View 4 (indicative: 640 controls in total)
    • One Form applet with 20 controls
    • Three Form applet with 100 controls
    • One List applet with 20 list controls
    • Three List applet with 100 list controls

If you want to grab the .sif file – go ahead 🙂 It contains the VBC, Applets, Views and Screen. You only need to register the screen in the application of your wish.

Ok, what have been my observations? Firefox is the winner with IE11 on the other end of the spectrum.

What would be your leading design practice: design & keep your views small 😉 No, really – the should be kept small if you want a view to render sub-second. And prevent at all times to enable too many list columns. The common reason “we need it for export” should be reconsidered. Where that might work in HI – in OpenUI it has severer implications. The JQGridRenderer has a noticeable overhead.

Do not forget that the timings below (in milliseconds) are measured between “PreLoad” and “PostLoad”. Those are JScript events of the OpenUI API. But these timings exclude further rendering time (such as CSS).