Help! My ViewState Is Out Of Control

Introduction

This article is about ASP.NET ViewState and how to minimize it. It discusses what it is used for in particular situations and what will be affected if it is turned off or fine tuned. This is an important topic if you write web pages that will be downloaded over a dialup connection and it may also be of interest to anyone who generally wants to reduce the bandwidth their pages take.

At the moment this article should be treated as an early version as I plan to add to it as I seem to keep discovering new things about ViewState. I also invite you to comment on other ways you've found to cut down on the amount of ViewState in a page. What did it affect? How did you re-implement the functionality that the ViewState offers?

What's not yet covered? The main topics that are not yet covered that I plan to add in the near future are Radio and Check Box lists, Data Grids and Data Lists. The sheer quantity of ViewState that a DataGrid emits sends shivers down my spine.

Background

I didn't find much good information about ViewState in ASP.NET, just the occasional reference to it. As a result some of the pages I have created in the past I had to rework because the ViewState was getting way out of control, and then I was left wondering how to re-implement the same features without using the ViewState. For something that can take a large amount of space (bytes) on a web page I felt it was an issue to be addressed. I also wanted a nice reference that I could go to when I needed to remind myself about ViewState.

Labels

So, you think a label won't store ViewState? It's static; it doesn't take input from the user. What on Earth does it need ViewState for?

A label that is defined in the designer, even although it has ViewStateEnabled=true doesn't normally have any ViewState associated with it. However, if you assign to the Text property of the Label object in code ViewState information appears as if by magic.

What's happening? Well, the ASP.NET looks to see if it needs to maintain changes between postbacks and if it finds any it will put that in the ViewState. If the EnableViewState is set to false the change of text value will not be placed in the ViewState and will revert to the value in the designer unless some code changes it again.

So how do I reduce the ViewState size? If the text will be the same for all page requests then you can put the text in at design time. If you can easily repopulate the text of the label for each page request you can save yourself some ViewState space by setting EnableViewState=false. If the text of the Label changes for each page request then there is no point saving ViewState information so, again, set EnableViewState=false.

Labels can also have tooltips. For more information see the section on Tool Tips below.

Buttons

Under most circumstances the button control will normally not need to store ViewState information because for the most part the button name is the same for every page request and this is set up in the designer (i.e. in the ASPX file and not the code-behind file). This is very much like the Label control. It doesn't look like it should need to store ViewState, but in certain situations it does. Also, like the label, it is changes in the Text property that is causing the values to be stored in the ViewState.

So how do I reduce the ViewState size? If the button caption is the same for all requests then set it in the designer. If the button caption changes and the time taken to retrieve the caption text is sufficiently fast then disable the ViewState and set it on every page request.

Buttons can also have tooltips. For more information see the section on Tool Tips below.

DropDownLists and ListBoxes

The ViewState of these controls stores all the elements of the list if you allow it. As with other controls, setting the list items in the designer will eliminate the need for ViewState information to be stored and setting the list items from code will cause ViewState to be used.

It is also worth noting that if you have EnableViewState=true and you set the Items in the code then make sure that this is only done on the first request. Subsequent requests will cause the Items collection to be populated with information from the ViewState. If you attempt to populate the list again from code on a postback, the Items collection will end up with duplicate entries and the amount of ViewState used will grow to accommodate these "new" items.

The difficulty with DropDownLists and ListBoxes is that you cannot just disable the ViewState and repopulate the list on each postback. What if the user selects something in the list? The change event won't get fired if EnableViewState=false. If you absolutely must eliminate the ViewState you will have to detect the change yourself and call the appropriate code to handle the change. You can check Request.Form collection using the control name as the key in the indexer method to find what value the user set in the control.

If you've decided that rolling-your-own change handler is too much work and want to retain the ViewState there are still ways of reducing it. If you populate a control like this:

myDDL.Items.Add(theTextString);

you could make savings if you used:

myDDL.Items.Add(new ListItem(theTextString, correspondingIDString));

if the correspondingIDString has fewer characters than theTextString. This is because, behind the scenes, ASP.NET sets the text and value components of the ListItem to the same string (if you only supply the one string) and both the text and the value is stored in the ViewState. If you are used to just setting one string when adding to the Items collection, then you will have to alter the code slightly because the SelectedValue will return the correspondingIDString. To get access the text as displayed in the control to the user use SelectedItem.Text.

CheckBox

The Text property uses ViewState in a way very like the Label or Button control does with its Text property, so I won't repeat the same things again. This control also supplies a tooltip property so see below for more information on that.

RadioButton

Again the Text and Tooltip properties acts like their counterparts in Label, Button and CheckBox, however Radio Buttons have another property that needs to be taken into consideration, the GroupName. If the GroupName is set in the designer then no ViewState is present. If the GroupName is set in the code then it will be present.

If you set the EnableViewState=false and the GroupName is set in the code-behind then the registered CheckChange event will not be fired. If you must eliminate the ViewState you will need to set up a custom handler for the event. The value of the selected radio button will be in the Reqest.Form collection with the GroupName as the key and the RadioButton.ID as the value.

Tool Tips

Even tool tips generate ViewState information. This is similar to the way the Label and Button control's generate ViewState for the Text property. Essentially, if the tool tip value is static it should be set in the designer (it won't emit ViewState if you set the value in the ASPX page). If it is dynamic and changes value on each page request or if it can be set on each page request fast enough then set EnableViewState=false and set the value on each page request.

Notes

During this article I have mentioned the differences between setting items in the ASPX file (or in the designer) and in the code-behind file. The effect is the same if the code that was in the code-behind file is move to a server-side script in the ASPX file.

References

For further reading on this subject:

• MSDN: Introduction to Web Forms State Management. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon/html/vbconIntroductionToWebFormsStateManagement.asp [^]
• MSDN: State Management Recommendations. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon/html/vbconchoosingserverstateoption.asp [^]
• MSDN: Developing High-Performance ASP.NET Applications. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpcondevelopinghigh-performanceaspnetapplications.asp [^]

History

• Version 1: 21-September-2003