There is no rule book explaining Best Practices for designing a Browser based InfoPath forms. Most of the times performance of the form depends on other factors such as volume of data, number of fields, design, overall farm performance, number of external connections, data rendering in the form(post backs) etc.
In this blog I am going to list some of the documentation from msdn describing the best practices to follow while designing a browser based InfoPath form.
A thing to avoid is multiple data connection queries on form load. It degrades the performance of the form drastically. Especially if your application gathers a large amount of data from the external sources. An alternate for this is to convert an external connection that stores static data into an XML file and add the XML file as a resource file. This would avoid the need of an external query. A drawback of this method is, if the data stored in XML file is changed, XML file should be updated with new data and form should be republished. It may become additional overload if the data changes frequently. It is suggestible to use this approach when you have data which does not change frequently like listing all the states.
Frequently posting data back to server can also impact the performance. It can be controlled using the post back setting for a control.
Some additional information from msdn:
How to use Business Connectivity Services with SharePoint Workflows:
Series of msdn blogs listed below clearly explains the best ways for designing browser-enabled forms for performance in InfoPath Forms Services:
There is no option from within InfoPath to use blob cache. This is due to the inability to return XML data from the blob cache out of the box. You will want to configure InfoPath as stated in the best practices documentation.
All the views expressed in this blog are based on my personal experience and may not hold good in every circumstance. All the links posted are references to msdn documentation.