Troubleshooting Form load performance issues in CRM

  • Artículo

Recently, I was working on performance issues with CRM Form load and after researching a lot on it, I found few good articles and blogs. I thought of sharing details about it which
will help you to understand the factors contributing to performance and how to deal with them.

The cost of spending time on optimizing your Microsoft dynamics CRM solution can take quite a long time for
a small benefit of a second or half a second on some forms.

In a CRM system there are lots of forms you can look at improving the performance of, so where should you
start. The main forms you should concentrate on

1)      The slowest forms

2)      The most used forms which are slow

Common reasons of slow form loading

The main culprits of slow loading forms are :-

  1. Busy Javascript onload functions
  2. Too many subgrids
  3. Lots of oData/fetchXML queries
  4. Tabs, sections and fields not needed on the form

 

To start the code optimization, the first step is to find the bottlenecks. The next step is to get a benchmark to see how they were loading, to get an average we loaded the
form 5 times and the results were quite varied.

Make a list of worst performing forms and had a quick look at them and make some quick notes

  1. How many unfiltered OData retrieves
  2. How many OData calls, where they retrieving the same set
  3. Number of ribbon buttons
  4. potential fields/functionality which could be removed by change of business process
  5. Size of JavaScript on load function.

 

Use Fiddler

One of tools you can use to analyze the slow loading of a form. It’s a great tool to see what calls are
being made from the page, how long they took and how much data they were bringing back.

Looking at the fiddler logs I was able to investigate the OData queries and find

  1. Which OData calls took the longest
  2. Find OData calls which were not filtered
  3. Find OData calls which were retrieving the same data
    multiple times
  4. general loading times of sections of code

 

F12 Debugger

  1. The F12 debugger is such an awesome tool for debugging Javascript.  I put in a break point in the onload Javascript and walked
    through the code.
  2. We are using two main methods to find slow loading code
  3. Looking at the code
  4. Stepping through the code

 

How to improve performance of Form load.

  1. Ask the customer to re-evaluate the fields and
    functionality on the forms.
  2. Improvements can come from moving fields and subgrids
    into unexpanded tabs where the loading can be delayed until the tab is
    expanded.

 

Subgrids

Subgrids take time to load and the more subgrids you have on a form the longer it will take to load.

Form load time can be saved by putting the grid in an unexpanded tab, this will not load the grid on
the form load but will load it when the user expands the tab.

 

Remove unwanted/unused fields

CRM Developers have to review and re-design their code then
I think CRM Forms and entities should be reviewed to remove the need of unused
fields.

 

OData queries

OData queries are a great way to retrieve data from related fields but if a form has a lot of them they can slow it down.  If
you use OData queries makes sure they are as lean as possible by filtering them.  

Below are some tips for using OData queries

  1. ALWAYS filter your OData queries to retrieve only the
    fields you need.
  2. Group OData queries to avoid multiple OData queries.
  3. Cache the return data in a JavaScript variable if
    different functions need the same data.

 

Common Libraries

CRM makes it easy for CRM Developers to write the same piece of code in every JavaScript file on every
entity and the same code in multiple plugins.  Code duplication is bad practice, it increases not only the possibility of bugs (e.g. updating code in one place but
not the other duplicates) but also increases time to fix a bug because you have to make the change in all the places the code is.

  1. Stop writing the same function in each JavaScript file for each different form.
  2. Create common libraries then it only has to be written once (and well) and then used again and again.
  3. The advantage of writing code once and used in many places is easy to maintain, debug and extend and you only need to
    test it once. If there is a bug you only have to fix it one place.
  4. Sometimes it takes more time to generalize a method but in the long run it will save you time.
  5. If you optimize this code it will save time in all the CRM forms it’s used.
  6. Always filter queries There is no use for getting all the fields back in a query because you never use all the
    fields.
  7. There are lots of retrieve code in CRM, it can be found in plugins and JavaScript but make sure the developers filter,
    always.
  8. Split loading times

 

Evaluate if you need all the data and checks to be done on the form load.  It’s possible you could move some of the functionality to

  1. Unexpanded tabs
  2. Onchange events

 

Unexpanded Tabs

You can put a subgrid in an unexpanded tab and load the subgrid when the tab is expanded.  If you have optionsets or other
fields which need to be calculated using retrieved fields then these can also be triggered on expanding the tab. This saves time from the form loading.

This would also save time if the tabs included Maps and iFrames.

 

OnChange Events

For some functionality it might be possible to delay some code and remove it from the form onload to a field onChange event.

 

Javascript files

  1. You can minify Javascript files which shrinks the size of the file and load quicker
  2. There may be some performance gains from combining 2 or more Javascript files into one Javascript file
  3. Plugins/Workflows
  4. Similar to moving Javascript functionality from OnLoad to OnChange events it may be
    possible to move some functionality to Workflows and plugins on the save of a
    record.  In general plugins run faster than JavaScript.