Improving Form Performance

When you load up InfoPath forms in a browser, do you see this message?

 

Probably. The important question is, for how long? Does the form open in a couple of seconds, or are you sitting waiting for minutes?

There are various reasons why a form might be slow in loading up. In this blog post, I’m going to cover the most common and explain ways to improve performance. A lot of the credit for the content of this post should go to Rafiq El Alami on the InfoPath team in Redmond for his presentation at TechReady on forms performance best practices.

If you have a form that’s loading slowly, ask the following questions. If the answer to any of them is yes, look below for suggestions that might help solve the problem.

1. Are several hundred controls (text boxes, option buttons, lists, etc.) appearing when the form loads?

2. Is the form doing lots of complex calculations?

3. Does the form have deep nesting (i.e. groups, within groups, within groups)?

4. Is your form requesting a lot of data?

5. Are your controls as simple as they can be?

1. Are several hundred controls appearing when the form loads?

Each of those controls takes time to load. Each may only take a fraction of a second, but those fractions add up. Each text box, drop down list and check box adds a tiny bit extra data for the form to download and display. When your form has a few dozen different controls, it will probably open in a few seconds. If you have a few thousand... you’ll be waiting minutes.

Plus, think about it from a usability angle. If someone opens up a form and sees thousands of controls, they’re going to be put off.

One way this can occur is when you have repeating tables or sections, within repeating sections. The form may load perfectly fine the first time but be a nightmare once a user has clicked the “add section” button a few times. Yes, repeating sections can be immensely useful under the right circumstances, but always bear in mind what will happen if they’re taken to extremes.

Another way to get round the problem of too many controls is to use views. You can create multiple views and display different controls in each, with back and next buttons triggering rules to swap between views. This way, the end result is still the same data being collected, but the user doesn’t get overwhelmed and the form will load up in a reasonable time.

2. Is the form doing lots of complex calculations?

InfoPath includes the capabilities for quite complex calculations, whether written in through the standard rule interface or coded into the form’s logic. This can lead to some very powerful forms being tied directly into business processes, but calculations take time.

The first thing you need to check is whether it’s really necessary to do the calculations. The answer is likely to be yes, otherwise you wouldn’t have written them in the first place. In which case, the thing to do is to decide when the calculations need to be done. Do they need to be done when the form is first opened?

Spreading out the calculations doesn’t reduce the amount of work being done by the form, but it significantly improves the user’s experience. Do calculations only when they’re necessary rather than when the form first opens.

3. Does the form have deep nesting?

When a form opens in a browser, most of the work is being done by that browser. The browser is not designed to deal with complex form logic. If you have deep nesting in the form, the browser is likely to send requests back to the server to ensure the information is being displayed and acted upon correctly. Each request takes time.

The simpler you can make the logic of your form, the easier it will be for the browser to handle and less requests will be needed. When designing forms, aim to have all your fields listed in the main data source window in a single line. I say to aim for this, I’m not saying you must have this. In large forms, you’re going to end up with some grouping, particularly if you use repeated tables or sections. But trying for a simple layout will mean that you avoid any unnecessary grouping that might slow down your form’s performance.

4. Is your form requesting a lot of data?

This is the big one. Do you have your form linking up to several databases, web services or lists to pull data into the form? If so, make sure that the data isn’t being pulled in from all of them right at the start.

You can easily set rules to query a data connection. For example, if you have a drop down list populated from an external source, add a rule to that list to query the data connection and select that the form doesn’t retrieve data on open. Now, the form will only query the data connection when someone goes to use the control. That way, if the list is optional and a user doesn’t click on it, the data is never requested. If you have multiple lists of this type, the time needed to retrieve data during form filling will be a lot less noticeable than if the lists all pull in data at the same time.

Only pull in data when it’s needed. You can link data connections to fields or buttons to ensure that the data is there when it’s required, but it doesn’t slow the initial loading.

5. Are your controls as simple as they can be?

Do you have a rich text box when all you need is a text box? Do you have a scrolling region when you just need a section?

Some controls are more complex than others. The simpler the control, the less time it will take to load. Try to simplify your controls. For example, there’s no point having a read only date picker. If you have a date field that is read only in a particular view, you can display it as a text box without altering the format of the data.

When you have things like combo boxes or multi-selection list boxes in your form, ask yourself whether they’re really necessary. The same goes for rich text boxes. Does it actually matter if the user can italicise their text?

Keep things simple and you’ll improve performance.