Filtering HTTP Responses
As part of a Microsoft Dynamics CRM implementation for a call center application, we were required to put a large number of edit controls on a single form, in order to satisfy the business requirement of having the fields available to the user during a call while keeping page navigation to a minimum. While we were able to spread the controls across different tabs on the form, in order to improve navigation and user-friendliness, we ran into a browser performance issue in production whereby the page rendering slowed significantly due to the large number of controls on the form. The problem was especially noticeable on machines with minimal RAM and slower CPUs.
We investigated several workarounds to this problem, but due to the requirement of CRM to only show one object per page, we were limited in the possible solutions we could implement. One solution included breaking up the entity to several smaller entities, which would require changes to data structures and introduce extra navigation that would ultimately raise the average handling time (AHT) for a user processing a call. Another solution involved using an IFrame in the form to host the data in our own page, which would give us the flexibility and performance we need, but at the price of a considerable development effort to implement the new page.
As a short term solution, we came up with a third alternative, which consisted of buffering the contents of the individual tabs into a javascript array on the server-side, so that the browser would not have to render the contents of each tab until a user clicked on that tab. This reduced the initial rendering of the page down to an acceptable time, and the rendering of each tab would only occur if the user accessed that tab. In order to buffer the contents of the tabs into a javascript array on the server-side, we implemented a custom HTTP filter for the form in question, which parsed and modified the HTTP output just before it is sent back to the client. The filter processes the outbound HTML by first removing the content within each of the tabs, writing out the modified HTML, and then writing out to a block of javascript which defines the array containing the contents of the tabs. On the client side, a tab click triggers javascript code which re-inserts the contents of the tab from the array, thereby delaying the rendering of the content until the user clicks into the tab. Of course, there are some concerns with this solution in general, most of which come down to the fact that this is not a supported solution from Microsoft, and that it will most likely not survive an upgrade path, but as a short-term solution it appears to work well, and did not require lengthy development time to implement. The following articles, along with Microsoft documentation, provided excellent resources for implementing an HTTP filter: http://www.dotnet6.com/blogs/erik_lenaerts/archive/2007/07/19/translate-content-using-a-httpresponse-filter.aspx
http://www.ondotnet.com/pub/a/dotnet/2003/10/20/httpfilter.html
JohnH