Is ASP.NET ViewState Slowing Down Your Website?
A challenge faced by web developers and designers is creating engaging, responsive, interactive web pages that load quickly and keep the user happy. ASP.NET is a fantastic web application development platform but using it can mean performance problems caused by viewstate.
What is viewstate?
Viewstate is a technique used in ASP.NET to convey changes to the state of web forms across postbacks. A postback is the exchange of form data with the server. The viewstate of a page is, by default, stored in a hidden form field in the web page named __VIEWSTATE and this is where problems can arise.
Why is it a problem?
The volume of data held in this hidden form field can become very large. This means increased page load times and, since all of the content of the hidden field must be exchanged during a postback, an increase in the time taken to complete an HTTP request.
Website developers who are keen to create slick, fast loading, low-bandwidth, user-friendly web pages can find themselves struggling to minimize the amount of data stored and exchanged as viewstate. And since Google have now confirmed that page-load-time is one of the many ranking factors used to determine where a page should appear in the SERPs there is even more incentive to make pages that are lean and fast. Perhaps more significantly, from an SEO perspective, the viewstate data generally precedes the important page content in the source order and can significantly inflate the page code.
What can be done?
Not being a programmer myself I asked an experienced ASP.NET developer (cheers Gavin) for his advice and recommendations for using viewstate and minimising the amount of viewstate data in a page. These were his pointers:
1) Generally, a site design should not rely upon viewstate. This needs to be decided at the outset as turning it off after a site has been developed can lead to unexpected results (and the site not working).
2) Consider using other forms of state control, for example session state, application state, manually populated/restored hidden fields, cookies. The ASP.NET Cache can be used to store data / repopulate controls to prevent unnecessary round trips to the database.
3) If using server side controls try and restrict usage to simple types; e.g. repeaters instead of data grids/views.
4) Viewstate can be eliminated from a page by not using server side forms or controls (runat=”server” tag), however the developer is then responsible for wiring up/coding form posts manually, the old fashioned way (Request.Form).
5) Viewstate can be turned off at the application, page and/or control level: (enableViewState=”false” tag). Even if you turn off viewstate for the entire application there will still be *some* viewstate on all pages (as viewstate is used to track which controls require postback). This is a trade off when using ASP.NET Web Forms and the postback model.
6) In most cases simply turning off viewstate in the control and ensuring you rebind any data on each post back will provide sufficient reduction in viewstate size. When doing this controls should be repopulated in the Init event, not Load event. Data binding during the Load event risks overwriting values which have been restored from the Form during the Load event.
7) You can find out which pages are viewstate heavy using a tool such as the ASP.NET View State Helper: http://www.binaryfortress.com/aspnet-viewstate-helper/
8) Large ViewState can be ‘chunked’ into a number of smaller fields using the maxPageStateFieldlength setting in the web.config file.
9) The ASP.NET MVC model does not use ViewState. Consider using the MVC model for the “front end” (publicly accessible) areas of the site, and the Web Forms model for back end administration areas where SEO is not an issue.
10) ASP.NET 4.0 Web Forms introduces the ViewStateMode property, which lets you disable viewstate by default and then enable it only for controls that need it (opt-in versus previous opt-out model).
Hopefully these suggestions will help developers who are struggling to shed a few kilobytes from their ASP.NET web pages.