@Thomas:

I totally agree. The first thing I deal with when optimizing a DNN site is to look at the size of the ViewState. If it's more than a few kilobytes it's going to be a problem. Processing ViewState is a complex operation. It's serialized,  encrypted and transferred with every request, postback and ASP.NET supported ajax callback. Optimizing jpegs is a waste of time with an elephant ViewState. Sometimes you can disable the ViewState for certain panes or controls by manipulating the skin-page. Otherwise you will need to throw out the modules with the worst impact and replace them with modules written by competent programmers.

The purpose of the ViewState is to save state information that is tied to the rendering of the view. All web frameworks do this by using hidden fields filled with state data. But since ASP.NET has made this so easy, many developers use the ViewState as a data cache. If the information can be recreated at the server side there is no need to put it in the viewstate. Instead the developer could use logic,  the application cache or the database to recreate the data. The ViewState is not designed to be a data cache.

When working with the ViewState it is important to be anonymous or logged in as a regular user, because the cancerous Telerik infested control panel  is totally out of control, ViewState wise.  

@Sebastian

I have just started the transition from the "brilliant, fast, production ready and rock bottom solid 4.9.5 version" to the "unstable 5.x alpha crap series born from too much time and funding on our hands, lets start crapping out all features we can think of and see what happens when we don't fix bugs version"  and haven't had the chance to test it out just yet. But I am certainly going to.