When creating ASP.NET pages one thing that usually doesn't get looked at too intensely by developers is the page's ViewState weight (I've been guilty of this myself). While there are various mechanisms to reduce the ViewState bloat in a page, the ultimate (uneloquently worded) question is, “How big is too big a ViewState?” Dino Esposito chimes in with some metrics in his blog entry ViewState Numbers [emphasis Dino's]:
You should endeavour to keep a page size around 30 KB, to the extent that is possible of course. For example, the Google’s home page is less than 4 KB. The home page of ASP.NET counts about 50 KB. The Google’s site is not written with ASP.NET so nothing can be said about the viewstate; but what about the viewstate size of the home of the ASP.NET site? Interestingly enough, that page has only 1 KB of viewstate. On the other hand, this page on the same site (ASP.NET) is longer than 500 KB of which 120 KB is viewstate.
The ideal size for a viewstate is around 7 KB; it is optimal if you can keep it down to 3 KB or so. In any case, the viewstate, no matter its absolute size, should never exceed 30% of the page size.
I think these are good metrics to live by when building apps targetted for the Internet. ViewState enacts a “double hit” regarding page load time. First, the user must download the ViewState bytes. Then, when posting back, that same ViewState must be reuploaded to the web server (sent back in the POST headers). And then, when receiving back the resulting markup from the postback, the ViewState (possibly modified) is sent back down again. So during a postback there's a seemingly double hit. That is, if it takes x seconds to download the ViewState of the page, when the user posts back it will take at least 2x - x to upload the ViewState and another x to download it back again. Cripes! (This is part of the reason AJAX is so appealing in Internet situations, although AJAX carries with it it's own slew of issues.)
When you're building intranet apps, where you know your user's will be connecting over a LAN, the page sizes and ViewState sizes are not as important as they impact the user experience much less. Most of my “real-world” projects have been created for the intranet setting, so I've not had to fret over ViewState size as much as others may have.
For those projects where a trim ViewState size is paramount, one common question is how to quickly determine the ViewState size (and, perhaps, what junk is actually being stored in there). For the ViewState size, I usually just do a View/Source and then highlight the ViewState content. (In UltraEdit - my text editor of choice - the number of bytes selected is shown in the toolbar.) To determine the contents of ViewState there are tools like Fritz Onion's ViewState decoder (for ASP.NET 1.x and 2.0) and Nikhil Kothari's Web Development Helper (for 2.0). I also provide code for a web-based ViewState decoder (for ASP.NET 1.x) in my article, Understanding ASP.NET ViewState.