Don't use viewstate compression! Use http compression instead!
Just google a bit with the keywords compression plus viewstate and lots of articles are to be found about this subject
like this one. The problem is that in most situations programmers are doing something that the webserver already can do for you. Not only does it compress the viewstate, it compresses all (dynamic ) documents that you configure it do to. It becomes even worse when the webapplication compresses its viewstate and the webserver compresses the rendered page output *again*. Seems a bit inefficient to me :-)
So let the webserver do in what it is good at. Serving/streaming rendered documents to the browser in the most efficient manner. Just configure it so that it is also compresses dynamic pages. If you dont know how to do this then just google on
http compression iss and lots of articles that explain how to achieve this. It really doesn't need an extra article from my hand ;-)
One situation in which it could be of interest is when an http 1.0 browser performs a request which does not support gzip compression. This way you can achieve nice results by compressing the viewstate. But in the article mentioned at the beginning of the page can be read that the viewstate would sometimes be larger then 1 megabyte. Well if that is occuring in your application then the viewstate data must be *really* expensive to calculate or read from a store must it be that important to add as viewstate data. In most application retrieving data from a data source actually performs very well although it always depends on the total count of page request, the total amount of webservers in a farm and the number of databases as is the kind of state required for some functionality.