Strategies for reducing ViewState size in asp.net

Question

I use 'n' number of server controls in my page. Now I am into performance tuning and I've noticed that my ViewState is too large and it makes my page slow.

I know ViewState size can be compressed by Gzip. Any other suggestions for reducing ViewState in asp.net. I don't want to do in IIS because my web application is hosted on a shared server.

Answer 1

Assuming the size of viewstate is the main cause of the 'slowness', I would like to suggestion you tackle it from a more holistic approach.

You have 'n' number of server controls, do you need all 'n' numbers to be server controls and not just plain HTML?

Say you really need all 'n' of them, do all of them need to have viewstate enabled?

Here is one good article (if you haven't already read) which provides more insights: VIEWSTATE size minimization

Answer 2

EnableViewState = false; should become your friend.

Assuming you currently are using viewstate ONLY where you need you can do the following:

1. Switch Labels to Literals, especially if you are using them in templates. Labels take much more viewstate.
2. Try do reduce postbacks. Less postbacks will make you need to use viewstate less as you will not need to reload the entire page. For example use AJAX calls and write out data via client side manipulation.
3. Use session or caching to store large amounts of data for grids and data heavy controls. With each reload, just fill it yourself.

Answer 3

Viewstates should only be used when you need to remember the state of the page between postbacks. It's used to prevent extra access to the database. So, if this isn't required in your control, use EnableViewState = False. If nothing on your page is going to need a viewstate, you can disable viewstates for that page by adding EnableViewState = False within the Page tag.

If your server can afford it, you may want to transfer data into Sessions. Do this if necessary for security (viewstate should not contain sensitive data), or if your viewstate is holding a large amount of data. Be careful as, by default, Sessions are stored in memory of the server. Therefore, you don't want to use this too much with large data if you're expecting many concurrent users. You can, however, change where the Session is stored (i.e. another server).