除了表单产生的HTML整体大小外，影响IPFS表现最常见的潜在因素可能是postbacks。一些表单控件、操作和功能要求用户的浏览器在填表过程中与服务器交流。数据交流被称为postback。并且它经常发生（当表单需要从用户的浏览器发送数据到服务器来处理，然后必须等待响应来更新并重新布局表单时）。这使得postbacks成为代价较高的绩效难题，因为每次表单postbacks发生时，它们迅速增加了请求网络的通信量。
注意：Postbacks只与浏览器表单相关，因为HTTP交流的无状态性。使用InfoPath Filler客户端时没有postback问题，因为InfoPath Windows客户端需要和服务器交流比同样的IPFS表单少得多。InfoPath客户端做了许多IPFS表单需要服务器做的事情，因此减少了网络交流。
因为IPFS表单如此依赖于服务器，postbacks有时不可避免。幸运的是，对于拥有最小化它们的知识和技术的表单设计者来说，这些问题可以缓解。有时，创建性能差的表单和好的表单之间差别不是消除postbacks，而是通过考虑到如果表单用户界面没有考虑性能而被创建时postbacks带来的问题，最小化它们。当涉及浏览器表单时，大多空间在控件属性上有个选项（回发设置）。这可能是少见的例外，通常，最佳实践是保留这个选项为默认设置。
知道postbacks的知识----为什么会发生和如何监控表单辨别潜在问题----你可以设计表单最小化postbacks，通常不会丢失重要的功能。
最常一起postbacks的情形有：
1. 数据连接
数据连接功能是创建查询连接到外部数据源----如XML文件、数据库、SharePoint列表或web service----这样表单可以抽取来自数据源的数据并更新。当数据连接被表单中事件激活时，如按钮点击规则，表单被要求和服务器交流来获取数据，从而产生了postbacks。
2. 计算
计算可能引起postbacks，因为计算经常需要服务器处理。
3. 切换视图
使用多个视图常被认为是改善InfoPath表单可用性和性能的最佳实践。通过仔细分组相关项目、限制每个视图中控件数目，而不是在单个视图中放置所有东西，你可以改善表单加载性能。所以最佳实践原则表明，视图是有用的，作为设计者的你应该明白每次切换视图时，一个postback发送用户信息到服务器，抽取新的视图，然后再浏览器中重载。
小贴士：如果你向监控切换视图postbacks，你可以发布第五章节“添加逻辑和规则到表单”的Blue Yonder Records Management Request form。使用Fiddler监控表单加载过程，然后看在表单中切换视图时发生了什么。注意每个视图切换是一个HTTP事件，本质上和重载完整表单相同。
4. 多个绑定事件
像插入或移除“重复表”和“重复或可选节”这样的事件也会引起postbacks。
小贴士：可选节postback类型的例子，你可以发布第三章节“表单设计基础：使用InfoPath布局、控件和视图”的Flight Delay表单。确保使用Fiddler捕获信息量。打开新表单实例，在Choice节，从超链切换到文件附件。
当在Flight Delay表单中做出选择时，如果你在Fiddler中查看活动，你将发现一个和下面图示相似的postback事件，由选项组中不同选项的选择而触发。
