Interactive Dashboard performance can be affected by careless IIS configuration - sanity check every time

1 minute read time.

Partners and administrators of end user servers need to know how to avoid some gotchas with the Interactive Dashboard (ID) in the 7.x releases. To help understand how to avoid accidentally affecting the ID performance for the end user, I will outline how it works from a top-level perspective.

The ID is coded using the Google Web Toolkit (GWT). GWT enables developers who are familiar with Java to code a nice UI experience that has all the advantages of a mature development environment that can be easily tested, debugged and unit tested prior to deployment to a production environment. When the UI is ready for production, GWT takes the Java UI and translates it to JavaScript. In fact, it translates it to several JavaScript files, one each for all of the major Web Bowsers (i.e. IE, Firefox, Chrom, Safari and Opera). Each browser JavaScript file is optimised for that particular browser.

Your Sage CRM 7.x installer will deploy all of the GWT browser optimised JavaScript files, even though we currently support IE only at the moment for the overall product (the ID is cross-browser). Now the ID production JavaScript file is quite big - around 5MB in fact. This gets loaded into the browser when the user navigates to the CRM Dashboard tab (if they have opted to use the ID instead of the Classic dashboard). Depending on the customer network this can take10 seconds or more. We expect that the browser cache settings are the default and the IIS settings are also default. In that case the ID JavaScript is cached on the users PC and all subsequent navigation to the ID will be nice and quick.

This is a potential gotcha if you change the IIS cache settings. For example, in IIS7, the default setting for Common Response Headers is as follows:

Now if you were to set the no-cache setting as below, the browser would never cache that 5MB JavaScript file and would re-load it every time the user navigated to the ID, leaving them with a big delay every time. Ouch!

So the lesson is to check the actual user experience whenever you change any IIS configuration settings.