Maximizing Browser Performance with the Salesforce Console

This article is about the Salesforce Console for service and sales. It does not refer to the Developer Console, or the new Lightning Console Apps coming in Spring ’17.

As we mentioned in an earlier blog post here, there can be a significant difference in Console performance depending on which browser you choose. This article will give you some implementation best practices to avoid performance degradation and provide code that can be used to systematically stress test and measure the impact of your customizations.

Disclaimer: The code presented works at the time of publication. Although our API is backwards compatible this post makes no guarantee of the functionality in the future or any compatibility with potential future console products or APIs. It is best used as a reference for your own implementation.

Implementation Tips

There are a few considerations when designing a console implementation that can help reduce or avoid performance problems entirely. The Salesforce Console makes heavy use of iframes, whose performance varies between browsers. For all implementations we advise thinking about ways to reduce the number of active iframes as much as possible.

Tab governance settings

The console has built-in functionality which can prevent users from opening too many tabs at once. Just like a regular browser, performance may suffer if you have 50 tabs open at once rather than a healthier lower number. Enabling tab limits will keep users from leaving un-necessary tabs open. Details on how to set this up can be found here. Our recommendation is a limit of 20 primary tabs and 10 subtabs.

Use visualforce components to reduce iframes

If you are using multiple visualforce pages as console sidebars or embedded into a page layout, consider if their functionality can be combined. The console will load each visualforce page in its own iframe. Combining them into a single page results in less frames and better performance. By creating multiple visualforce custom components to build a single visualforce page you can reduce the overhead compared to using multiple visualforce pages individually. You can learn more about visualforce custom components here.

Avoid opening multiple tabs automatically

As an example, let’s say you have a visualforce page which gets opened when a call comes in from your CTI adapter. This VF page also opens 4 subtabs when it loads: an account, contact, case, and lead. This means every call that comes in will open 5 tabs in your console, even if your agent does not necessarily need them all. In a high volume call center this can rapidly add up.

A better option would be to open a VF page which has one or more buttons that open each of those other kinds of tabs when clicked.

This is of course a balancing act between optimizing your agents’ workflow by shortening click paths and the performance impacts of doing so. If you’re wondering how to determine what impact such a change has in order to make a data driven decision, you’ll love the next section.

Testing the Performance of your Implementation

As mentioned in our earlier blog post, Salesforce runs nightly performance tests to evaluate the memory profile of certain actions. We’re happy to provide a portion of this code in order to help you do your own rigorous testing in a way which aligns with our own. This can help you determine the impact of each specific customization as you put it in place, allowing for better performing implementations.

Throughout the rest of the article we’ll create a custom console component which can open console tabs automatically in order to simulate a high volume support center.

Step 1: Create an apex class

This code is simply retrieving the records whose tab will be opened during the test. If you need to work with other entities, custom objects, or with a specific subset (based on record type, created date, or any other filter) you can simply create additional methods to select those records.

Step 2: Create a visualforce page.

This page lets you choose which type of object to work with and which test to run. You can extend or modify the javascript in order to run different tests, as well as update the picklists if you added new entity types into the controller.

The four tests which are included in this page are:

Open 10 primary tabs at once, wait for them to load, and close them. Repeats this 30 times. This helps simulate behavior like receiving multiple chats which open related records at the same time.
Open 1 primary tab then closes it. Repeats this 100 times.
Opens 1 primary tab and 1 subtab. Closes the subtab. Repeats opening and closing subtabs 100 times.
Opens 25 primary tabs at once. Refreshes them all at once. Repeats refresh 10 times.

It’s a simple matter to provide different parameters to the above tests, allowing you to open a simple tab 1000 times for example. Find methods with names like ‘Baseline01OpenCloseTabs’ and edit the variables that contain these values.

Step 3: Create a console component

From Setup, click Customize | Console | Custom Console Components and then click New.
Give the custom component a name and a button name
Under the Component option select Visualforce Page and enter the name of the page you created in step 2
From Setup, click Build | Create | Apps and edit your console app. Under ‘Choose Console Components’ move your new component into the Selected Items list and save your changes

Step 4: Run the test and observe the results.

You’re now ready to begin. Enter your console app and open your new component. Select the object to test from the picklist and press the button for the test you want to run. Use a tool of your choice to measure the behavior of your browser’s memory over time, as well as comparing the values at the start and end of the test.

We recommend the use of Performance Monitor in Windows to monitor the private memory usage of your browser process. More information about using this tool can be found here.

After you have established a baseline with the tests, you can make your implementation changes and run the tests again to compare the results. If the changes you make result in excessive memory consumption compared to the baseline, it’s time to consider ways to optimize your implementation. You can also compare the behavior to the baselines established by Salesforce in our blog for a default console to confirm if the performance deviates from standard.

That’s it! Hopefully arming yourself these implementation and instrumentation tips will help your console reach new heights of performance and user satisfaction.

The future of Console

Starting in Spring ’17 the console is getting the full Lightning treatment. All-new Console Apps built natively on our Lightning platform will be available, including full support for Lightning components. Best of all, this new console taps into the performance and optimization that’s done across the entire Lightning Experience. This means you’ll get the same great performance inside the console as out of it.

Be sure to check out the release notes and roadmap for more information on the latest and greatest console features.