Designing browser-enabled forms for performance in InfoPath Forms Services (Part 1)
Part 1 - Introduction
InfoPath Forms Services (IPFS) is a Web service system integrated with SharePoint that enables you to deliver InfoPath forms on the Web through a browser. These browser-enabled forms extend the reach of your forms system, since your users do not require the InfoPath rich client to display and fill out the forms. When you are designing browser-enabled forms, optimizing performance should be an important objective for delivering the best possible form filling experience to your users.
To help you reach this objective, we are introducing a series of articles about optimizing the performance of InfoPath browser-enabled forms. We will cover design issues and enhancements that can either degrade or improve the performance of your InfoPath forms system. Information in this series will help you gain a better understanding of differences between an InfoPath rich client form and a browser-enabled form, the interaction between the browser and the IPFS server system, what form features cause postbacks, factors affecting the rendering of a form in the browser, how to identify problems and monitor the performance of your forms system, and other tips for improving the performance of browser-enabled forms.
Who should read this?
Who should read this series about designing InfoPath browser-enabled forms for improved performance and scalability? First, anyone who is interested in learning more about the design and delivery of InfoPath forms on the Web. Second, anyone who has to design and support large or complex forms. Third, anyone who needs to support a significant number of concurrent form users and is concerned with the performance and scalability of their Web form system under load. Whether you are an experienced form designer or are new to InfoPath, the information in this series will help you improve your understanding and control of the behavior of your InfoPath browser-enabled forms.
What do we mean by "performance"?
When describing the behavior of InfoPath browser-enabled forms on the Web, what do we mean by "performance"? Simply put, "performance" is the subjective perception of how responsive the form feels for the person filling it out in their browser. This perception is influenced by how quickly the form loads and how quickly it reacts to the user's input. Performance is good when your users don't have to wait for a form; it is bad when they do. As a form designer, your primary goal is to manage the overall user experience, and your primary performance goal is to minimize the time your users spend interacting with the forms. At the same time, it is equally important that your server system be able to scale to meet expected demand while maintaining an acceptable level of responsiveness. Of course, these are not your only goals - you must also deliver a form that meets a stringent set of design, business, and technical requirements.
Just as good form design requires balancing design and layout with business and technical requirements, good form performance happens as the result of a complex set of factors. Some of these factors might be outside of your direct control as a designer, but they must be considered in your design to achieve your performance goals. Some of these factors include: the user environment, expected usage patterns, peak loads, network and server architecture, database design, custom code, and interaction with other applications in your SharePoint environment. The more you know about these factors of your form deployment and how they interact with your form design, the more effectively you can manage the issues that affect browser form performance.
Generally speaking, some of the most important objective measures for gauging performance are response time, throughput, and resource utilization. These measures can be used on the server to evaluate how efficiently requests are being processed. They can also provide insight about whether an issue is occurring on the server or in the browser. Use these measures to analyze actual performance, develop baselines, and understand the effect of your changes during troubleshooting and tuning activities. Although beyond the scope of this series, as you develop your framework for evaluating forms performance under various conditions, you should plan on developing load, stress, and capacity testing around these measures. The more objective you can become about performance, the more effective you will become at finding and removing performance bottlenecks. Later in this series you will learn more about tools for monitoring the performance your InfoPath forms system.
Ultimately, because each environment and set of form requirements is unique, there is little prescriptive guidance that is both general and specific enough to be useful. As you optimize rendering performance in the browser, throughput might increase, but certain improvements in throughput might in turn reduce the responsiveness of a form in the browser. Or it might increase resource utilization on the server, reducing the server's ability to scale when subjected to heavy loads. In the end, you must make decisions and tradeoffs to resolve the various elements of form design with respect to the characteristics of your system, and your design, business, and performance goals. Armed with the information presented in this series of articles, you will be better equipped to make decisions that improve the performance of your InfoPath browser-enabled forms.
Common causes of poor performance
There are many conditions that can put a drag on the performance of browser-enabled forms in an InfoPath Form Services system. The following list is a sample of some of the most common conditions:
Slow network connections
This is an important factor in the actual performance of any server system, especially one that uses the Web. It’s something you should keep in mind as you design, test, and deploy any web-enabled form. Although there are many things that affect performance at the network and system level, and that can be done to improve it, these are beyond the scope of this series.
Large amount of HTML
Large forms that require large amounts of HTML to be transferred and rendered reduce the responsiveness of a browser-enabled form. Rendering performance will be the subject of an article in this series.
Large amount of XML
Again, large, complex forms can contribute to poor performance of an InfoPath Forms Services form system. Since Forms Services processes form XML on the server, forms with large amounts of complex XML require additional server resources. When there are many concurrent users, the additional stress on the server reduces scalability and throughput, and increases latency. In addition, a large amount of XML can slow form rendering in the browser. In this series we’ll look at a number of issues that make form processing more expensive.
Form features that cause postbacks
Certain form controls, actions, and features require the browser to communicate with the server during the form-filling session. This exchange of data during the session is called a postback, and it usually occurs when a form feature needs to send data to the server for processing and then has to wait for a response to update and re-render the form. We’ll look at specific features that cause postbacks in our next article.
What's next?
The next article in this series will look at some of the differences between InfoPath rich client forms and browser-enabled forms that have implications for performance. The most significant difference involves the postbacks that the browser sends to the server for processing. Whether you are familiar with InfoPath or you are new, you will learn something new and useful about the interaction between the browser and the InfoPath Forms Sevices server system.