Designing browser-enabled forms for performance in InfoPath Forms Services (Part 4)
Part 4 – Browser Rendering Issues
Welcome to the fourth article in our series on optimizing the performance of InfoPath browser-enabled forms. In our previous articles we defined performance in terms of responsiveness, listed a number of conditions that cause postbacks, and looked at some of conditions that make postbacks more expensive, reducing the responsiveness and scalability of a form system. In this article we’ll examine some of the issues that affect form rendering performance in the browser. We’ll also take a quick look at using the Design Checker to monitor browser compatibility issues while designing a form template in the InfoPath Designer.
Conditions that slow form rendering in the browser
There a several conditions that can reduce form-rendering performance in the browser. The main effect of these conditions is that the user experiences delays and sluggishness when working with the form. The reduced performance experienced because of slow form rendering in the browser generally occurs at the following times:
When the form initially loads
When the form is updated and re-rendered after a postback response
When there is a change to the display of the form in the browser that does not involve a postback
If the designer can reduce or eliminate conditions that are more expensive for the browser to render, the form will render more quickly, and feel more responsive to the user. As with other design issues we’ve examined that affect postbacks and server performance and scalability, addressing performance issues that affect browser rendering must be balanced with your unique design and business requirements.
Rich Text Box control
The Rich Text Box control creates HTML elements for the content added to a rich text field. Depending on the amount of content and formatting added by the user it can end up creating a large number of HTML elements, which can impact browser performance. One issue with using a rich text field is that you cannot predict how much data a form user might add to the field. For example, a user could paste a large rich text selection into your form from just about any source. Although the Rich Text Box control for a browser-enabled form does not allow embedded images, only linked images, the content could still be quite large.
Unfortunately, for browser-enabled forms the InfoPath Designer does not provide a way to limit the amount of data entered. Consequently, you should consider carefully how your users are likely to use any rich text fields you add to the form and limit the number of rich text fields that are visible in a view. If you need multiple rich text fields, consider using multiple views rather than putting them all on a single view. As an alternative, consider using a Multi-line Text Box control instead.
Nested Tables
Rendering HTML code for tables is a relatively expensive operation for a browser. Nesting tables by inserting one table inside another, especially if they are nested several levels deep, compounds the complexity and is generally slow for a browser to render. For better rendering performance, consider using adjacent non-nested tables rather than nested tables.
Conditional formatting
We looked at conditional formatting in an earlier article, touching on the interaction with postbacks to the server and how conditional formatting expressions fire each time the form is re-rendered. Since the browser must manipulate all the data, whether it is visible or not, this can be an expensive operation that makes the form display feel less responsive. While conditional formatting can be a useful design tool, there are times when the performance cost may outweigh the benefits. For example, if a form contains a large amount of data and a substantial part is hidden, the conditional formatting can slow the form display even though some of it isn’t rendered.
In this case, designing the form with multiple views might improve the form’s display performance compared to the single view with hidden content. Although it will cause a postback each time there is a switch to another view, the user’s interaction with each of those views in the browser may feel more responsive. This is because each view has a smaller amount of data to render than the single view containing hidden data. The tradeoff you need to consider here is between the browser-side responsiveness of the form display and the server-side scalability of your form system as it processes postbacks: using conditional visibility might slow form display, but reduce the number of server requests, while using multiple views improves form display, but increases server requests and reduces scalability.
As another example of how subtle performance tradeoffs can be, as noted in the earlier article, it is also possible to have a design where the form display is more responsive if it uses conditional formatting to hide some data. This is happens in a situation where the browser actually takes longer to render all the elements than it takes to process the conditional formatting and hide some.
If you suspect you have a situation where conditional formatting could either help or hinder your form’s performance in the browser – or your server scalability – try alternate designs and test them to determine which design best meets your requirements.
Drop-Down List Box controls with many items
Drop-Down List Box controls can generate a large amount of HTML, especially when there many items provided in the list. The amount of HTML balloons when the list control is contained in a repeating section or table. For example, if you include 50 items in a list, and the list is repeated 50 times, the underlying HTML code will grow very rapidly and slow down rendering of the form! Try to limit the number items in lists that are used in repeating elements or limit the number of repeating elements. Alternatively, you can try using conditional formatting, putting the repeating elements containing drop-down lists into a section that is hidden by default. Because they are not supported in browser-enabled forms, some of workarounds you might consider using if you are familiar with InfoPath rich-client forms, such as a Master-Detail control or one of the other list controls, are not available. About the only other alternative might be to emulate the list using a repeating table with each item on a row (and some fancy formatting). One situation to watch out for is using an external data source to provide the list items. If you need to do this, then you also need to make sure the number of items provided by the data source is limited to a reasonable number. As with any design, it is always a recommended best practice to test alternative designs for expected (and exceptional) data sizes to determine how your form designs perform.
Many visible controls
Forms that have a large number of InfoPath controls visible in a view will reduce browser performance. Again, this is amplified when the controls are in repeating sections or tables. The first suggestion is to use multiple views so that each view has fewer controls to be rendered. If you use multiple views, make sure that controls are only bound once in the view in which they are used (use the Design Checker). Once again, you can also use conditional formatting to hide some of the controls, but this will typically achieve a smaller gain in browser performance compared to using multiple views. Because there are a number of important variables that determine browser rendering performance, your design alternatives should be tested in the common user environments you expect (data size, browser type, user's machine configuration) to determine acceptable number of controls and the relative performance of each design.
Calculations that use large data sets
If you design a form that includes calculations and the data for the calculations is loaded from an external data source, then that data will be downloaded to the browser so that the calculation can run in the browser without a postback to the server. Normally this strategy improves overall performance by reducing postbacks. However, if the data set is large, the benefit of eliminating postbacks can be overtaken by the performance cost of handling the data in the browser. First, it is more expensive to load a large data set; second, it is expensive to run after it is loaded.
If you find that the browser is too slow when running calculations with large data sets, you can force a postback so that the calculation runs on the server instead. In the InfoPath Designer, for the field that runs the calculation, add a button and change the postback setting to always require a postback. When the user clicks the button to run the calculation, it will postback to the server to evaluate the calculation and return the result to the browser for display. Like most performance suggestions, you need to balance performance in the browser with the performance and scalability of your form server system.
Reporting scenarios
InfoPath is primarily designed to address form-filling scenarios. Although it can also be used to display data in a reporting scenario, this can have a negative impact on browser performance as the amount of data downloaded for display increases. If there is a possibility that the amount of data could be very large, then you can expect performance problems not only in the browser, but also on the server. Depending your ability to predict and limit the amount of data in a reporting form, it might be possible to maintain acceptable performance by using multiple views and read-only controls. However, if the data is too large or cannot be limited practically, you should consider an alternate reporting solution.
Internet Explorer 6
If you have form users that are using Internet Explorer 6, they will experience reduced browser performance compared with other browsers due to known issues with IE6 JavaScript performance. You might consider providing a statement on your site about browser support, and if you know you have a substantial number of users running IE6, then it is a good practice to include IE6 performance testing in your development plans.
Use the Design Checker to monitor browser compatibility issues
The InfoPath Designer allows you to design forms that run in both the rich-client and a browser. When you are designing browser-enabled forms, and especially when you want your form to support running in both environments, you need to be careful about browser compatibility issues. As you are designing a form template in the InfoPath Designer, you can use the Design Checker task pane to monitor any browser compatibility issues detected by InfoPath, including those that affect performance.
Among the messages displayed by the Design Checker are warnings for controls that will trigger postbacks to the server (these messages are hidden by default; to view them, select "Browser Optimization Messages" from the Options button at the bottom of the Design Checker). One or messages can appear for each control that will post back to the server when the value of the control changes.
Sometimes the postback occurs because of a calculation, binding, or other expression on that control. Occasionally a control will post back to the server not because of a property on that control, but because that control is contained inside a section or a table where some other control forces a postback, or the control contains a section, table, or other controls inside it that cause a postback. In these cases, the warning messages indicate that you should look for another control marked as a primary cause of the postback; examining the messages for that control can help you locate, understand, and control postbacks caused by related controls.
If having other controls bound to the same element or group are causing unwanted postbacks, consider using separate views, with the control bound once in each view.
To resolve issues where the binding of the control requires server evaluation, or a node is listed as only available on the server, you might need to simplify your schema.
You can change the default postback behavior for an individual control using the Postback settings options on the Browser forms tab in the Properties window for the control. There are three options available: Never, Always, and Only when necessary for correct rendering of the form (recommended). You can reduce the number of postbacks by changing the setting to Never. If you select Never, then the control will not send data to the server on change; the data will only go to the server and formatting, calculations, etc. will only run when the form user saves or submits the form, or another control in the form causes a postback to the server. For controls you want to change, you must change the postback setting option on each control individually; changing the option on a section or group control does not automatically change the value for every control inside it.
Note that you should carefully consider the effect of changing postback behavior to ensure that the result is acceptable for your environment. Be careful about suppressing postbacks that affect the user’s form-filling experience to avoid issues where displayed data could be incorrect. You never want to sacrifice data integrity for a potential gain in performance. If you make any change to the postback settings, it should be thoroughly tested to ensure the form behaves correctly.
What’s next?
The next article in our series provides information on some of the useful performance monitoring counters that can help you evaluate the performance of your form system.