Thanks to Gautam Vasudev and Jason Ding for inspiring this blog!

If you are interested in understanding how the Salesforce Console, an application which is used by contact center agents throughout the day, performs on different browsers, read on! If you are crunched on time, my general conclusion is that Chrome and Firefox browsers perform way better than IE with Chrome being the clear winner. Within IE, IE9 far outperforms IE7 and IE8.

The Salesforce Console was designed for high volume call center Agents (Tier 1 customer service/ Tier 2 & 3 product support). The console allows streamlining customer support by boosting agent productivity.  The Salesforce Console (previously known as the Service Cloud Console) has now evolved numerous features and provides enhanced capabilities that can be used in both sales and service use cases; in fact any domain where the user wants to look at or edit multiple records simultaneously. The primary and secondary tabbed environment of the Console helps facilitate this multi record view.

This blog demonstrates the behavior of the console in different browsers with a focus on performance from an agent perspective. I have measured some primary metrics that are important from an end user perspective when using the console on a day-to-day basis. Consequently, I have focused on the browser memory consumption and on the console load times in the console.

For the sake of familiarity we will focus on contact center use cases with the case object being the primary record of interest. The numbers stated in this blog were observed when all the common out of the box features for the Console were enabled. We chose Internet Explorer 7, 8 and 9; Firefox (v21) and Google Chrome (v30) because most of the console users across the globe are using these browsers.

All numbers mentioned below were generated on lower configurations virtual machines hosted on remote servers to emulate challenging remote desktop agent environments. The numbers mentioned in this blog were generated in an environment that amplifies the differences between the browsers. These differences in performance are less noticeable in more powerful machine configurations.  Salesforce.com continues to  focus on improving the Console in IE8 and IE9 to bring performance at par with more modern browsers

VM configurations

CPU Model: Xeon E5-2680

Memory: 4GB

Operating System: For Firefox and IE9 tests Windows 7

For IE7, IE8 and Chrome tests Windows XP

Scenario 1: Memory Utilization

Contact center agent machines come in all types of configurations. At the lower end of the spectrum they have limited memory and processing power. In such a configuration, there is a strong relationship between memory consumption and browser and system performance. For efficient performance, efficient memory management in the browser is critical.

A number of factors affect memory consumption in the Console. The two primary contributors are –

–       Number of open tabs. How many cases are your agents working on at the same time? Do they have 5 case tabs open in the Console or 10?

–       Workspace configuration. Does your case primary tab have subtabs? How many sidebar components are present? How many footer widgets? Each of these is an iframe, which is like a little web page of its own. Add too many of these and memory consumption shoots up

Let’s consider a spike use case where an agent has ~12 tabs open in the Console at the same time. The numbers below depict how the memory consumption of the browser fluctuated for different browsers.

* Garbage collectors behaves differently from browser to browser, and even a lot of memory retained after closing tab doesn’t imply that those memory space is “leaked” permanently.

Takeaways:

For a spike in Console load, Chrome leads with the least memory utilized for opening tabs and the memory released after the tabs are closed. IE9 follows, being marginally more performant than Firefox 21. IE7 and IE8 lag far behind with the most memory needed to handle the spike and the most unreleased memory after the spike load tabs are closed.

Your choice of browsers should be determined by how many Console workspaces your agents work with at the same time and the configuration of these workspaces. Keep in mind however that this decision depends not only on a single load spike. The unreleased memory in the last column is important as it affects subsequent Console performance through the rest of an agent’s day. Some browsers are much better at releasing this memory over time than others. More in the following section.

Scenario 2: Memory Utilization through the Day: Which browsers your agents love…

During the course of the day, agents open and close several tabs. One would assume that as agents open and close tabs, all the memory consumed by the browser corresponding to those console tabs would be freed when the tabs are closed. Unfortunately this is not the case. This results in iteratively increasing memory consumption by the browser affecting the performance.

Under the assumption that on an average day, every agent would spend a minimum of ~1.5 mins working on any tab before closing the tab, typically agents would open and close less than ~300 tabs a day. The next section discusses the browser memory consumption behavior when opening and closing 300 tabs sequentially in the console without reloading/refreshing the browser console window.

* Garbage collectors behaves differently from browser to browser, and even a lot of memory retained after closing tab doesn’t imply that those memory space is “leaked” permanently.

Takeaways:

Your agents are impacted significantly by memory degradation through the day. Memory is released/ garbage collected at various times, but this memory management varies from browser to browser. Internet Explorer 8 is the worst offender in this regard, even more so than IE7. What this translates to is a slowing Console as the day progresses and agents use more and more tabs.

On the other hand, Chrome and Firefox do a much better job of handling a full day’s workload. This is also reflected in the feedback sent to us from agents and customers who say that Chrome and Firefox just seem to be faster and more responsive than Internet Explorer.

It’s interesting to note that while Firefox was less memory efficient than IE9 at handling a Console spike load, it is much more efficient in the long run. This makes a significant difference in usability. Agents are less likely to notice slower performance for a spike, but definitely notice if it persists through the day. Firefox eventually releases most of the memory used, while IE9 doesn’t.

We also ran this test with Firefox 24 on an 8GB Mac book (OSX). The memory consumption spiked to 720MB! However, performance wasn’t impacted at all. The truth is that as more memory becomes available, applications try to optimize for performance with all the memory available to them. In this, case since there wasn’t any scarcity of memory, Firefox optimized for performance. We’ve continued to mention the high memory Firefox 24 results below for contrast.

Scenario 3: Console First View

Let’s move on from memory to UI performance! How do the various browsers measure up when it comes down to seconds and milli-seconds?

‘Console First View’ implies first time load of the console. The load for the console implies the least amount of time before which a user can start interacting with the console. The time to open the first tab and to reopen a tab indicates how effectively the browser caches the tab resources. The numbers below are averaged over several iterations.

Our Firefox 24 in the 8GB OSX MAC book, the Console first view time was 3 seconds. The time to open the first tab was 3 seconds and to reopen the tab it was 2 seconds, comparable to Chrome.

Takeaways:

These numbers indicate that except for IE7 and Chrome outliers, the console behaves almost similarly in all the other browsers with respect the load times. You can also see that caching makes a difference as the second cached opening of the tab opens much faster than the first un-cached opening.

Scenario 4: UI Performance through the day: Which browsers your agents love part II

In this scenario, we look at the tab load times in the console after agents have worked through several tabs, simulating progress through the day. To get a better understanding of how browser performance degrades after several tabs have been opened and closed, I have considered two different use cases.

–       Tab load times after opening and closing 40 tabs

–       Tab load times after opening and closing 300 tabs

On our Firefox 24 in the 8GB OSX MAC book, 40 tabs opened in 1.8 minutes and 300 tabs opened in 13.1 minutes. Time to open the 41^st and 301^st tabs were both averaged 2 seconds.

Takeaways

While initial load times are important, it’s the consistent use performance of a browser that has the most impact on agents. In this regard, IE7, IE8 and IE9 performance degrades consistently through the day. Initially these browsers performed comparatively well (see previous section), but that doesn’t last long.

Final Thoughts

It’s clear that Google Chrome comes out on top is almost every category. Can the discrepancy really be this large? We were wondering about this too, especially with Firefox.  We decided to include Firefox 24 on a well configured machine to test this. Our Firefox 24 in a 8GB OSX MAC book was able to stay in tune with Chromes performance for the most part.

However, Chrome shone even in our “challenging” environment. If your Salesforce Console agents are using machine configurations that are low memory and in a remote desktop environment, this is the best option for you. Chrome has been built with efficient memory management techniques and has in-built code/JavaScript optimization methodologies which result in better page load times. This helps it to provide the same experience to users irrespective of the amount of work that has been done in the browser. We see this when opening the 301^st tab in chrome is very similar to load the 1^st tab in the browser after a fresh login.

Firefox comes second to Chrome with reasonable performance in low config environments, followed by IE9. IE8 and 7 start reasonably well, but experience severe degradation as the day progresses. It will be interesting to see how IE10 and IE11 compare as we expand this testing in the coming months.

Going forward, it is always going to be the console in the Google chrome web browser for me!

If you are interested in simulating some of this yourself, the script for opening and closing tabs was executed in a Custom Console component. The script opens 4 case tabs at a time, waits for an interval, gets all the opened tabs and subsequently closes them. The Salesforce Console Integration Toolkit API commands for this are openPrimaryTab, getPrimaryTabIds and closeTab. I look forward to hearing from you in the comments!