Some customers extensively customize their CRM installation so that CRM is optimized for their unique business scenarios. When you add a lot of fields on an entity form you might notice it’s load time increases. The performance is not hampered on “out-of-the-box” Microsoft Dynamics CRM configurations. For the majority of users the default settings work fine. But for heavily customized installations, performance can become an issue.
Inside Form Controls
In CRM v4 we actively utilize DHTML behavior scripts. These, small, scripts, reside in files with HTC extension and can be attached to HTML elements using “behavior” keywords in an element’s style definition. That lets developers enhance the standard element’s behavior in various ways. A very powerful mechanism for web UI development, this mechanism can have problems in the IE implementation.
Almost every CRM form control (internally represented by some HTML element) has an HTC behavior file attached to it. In addition to its own unique behavior script, every control also has so-called “data slug” (or simply, “slug”) behavior script attached. An example of slug is shown below.
Slug in Create Account dialog
Even though slugs on dialogs are only needed in a very limited number of cases, mostly from Workflow/E-mail templates creation forms, the corresponding behavior scripts are attached to the elements every time a dialog is loaded. Unfortunately, the time IE spends to parse a page with behavior scripts attached to it, is in the direct proportion of number of attached instanced and number of JS blocks within the script. That’s how the form load time increases; the slug support script attaches to every control and it has a lot of JS blocks in it.
Now, having all this information, figuring out how to improve the performance is easy—we would remove slug support from where it was not needed.
New Form Control Performance
Depending on a number of custom fields, form load time (the time between clicking New button on an entity list and the moment when entity dialog is shown up and ready to use) could reach 10-20 seconds. The new behavior decreases this time to 4-6 seconds which is a 60-70% win. The time diagram below helps illustrate the timing here.
Besides some obvious things like only adding attributes to forms that you will actually use and verifying your custom JavaScript code for performance, you could also check to see if the antivirus running is on your client machines has poor performance. Sometime an antivirus has inefficient script scanning modules. This would significantly slow down scripts executed in IE.
Where can I get this performance enhancement?
This new behavior is already available for CRM Online users and has been released as a part of Update Rollup 5 for On Premise users.
A tip of the hat goes to CRM MVP Aaron Elder who discovered this solution.
Cheers,