Saturday, 8 October 2011

Compress ViewState AND/OR Http Response Before It's Too Large (ASP.NET)

I saw a few users rated our site down lately and all seems to be from countries far far away. This, I figure, could largely due to the fact that the size of the HTML code generated by our pages has gone wild and made our user sick in waiting.

For your information, I've tried to make our site feature rich by throwing a lot of AJAX server controls from the ASP.NET Ajax toolkit. While the functionality of the site got improved conceivably, the Java Script spit out by such controls also puff up the page size considerably. Another culprit is, as you may have already guessed, the viewstate. I stuff a lot of user controls in the page and each would chip in a lengthy chunk of viewstate that need to be bounced between to the user and the server. What makes the thing worse is that the user controls are there to provide some multi-step wizard type of funciton which would trigger post back multiple times.

Replacing the user control with web service and AJAX backed components can be tempting but I'm more into RAD, especially when my thesis is in the area of biochemistry rather than computer science. What can I do?

The first thing I thought of is to store the Viewstate on the server rather than push it down to the user. ASP.NET 4.0 has made it easy for aspx page to persist the viewstate locally on the server. But for some reason they did not do the same for the user control and their viewstate still need to be stored in the page that contains them.

Compressing the page generated seems to be the logical answer and this again can be easily done especially in IIS 7: A tick in the appropriate checkbox is all you need.



This would compress both the Java Script and Viewstate generated by the user control at the same time. However, it is not the silver bullet that can solve all my problems. Although this would allow the deflated viewstate to be pushed down to the user through a faster downloading pipe, the inflated version would need to be uploaded back to the server via a usually slower uploading link.

Therefore, unlike some post suggested, compressing the viewstate prior whole page compression is still necessary. However, I'm yet to see any solution to do this possibly due to the lack of mechanism to overwrite the save viewstate method or indicating the persistance medium.