I'm next to test a solution to move Viewstate to disk/cache/db with a page adapter overriding the HiddenFieldPageStatePersister

Now my doubt is... I saw there are already several .browser files in App_browser so if I create a new one for "default" browser to override the page will this break things up? Should I add  the lines in all the existing .browser files?

Hallo Leupold! Usually I agree with you but in this case, even if I agree that more resources are moved to the client and that's good, reguarding the viewstate I think the default Microsoft implementation is awful. The viewstate is only needed on the server but is always sent back and forward on each post between the client and the server, so you'll have 300/600/1000 KB of data (and relative download/upload time) going back and forward between client and server for a resource that is only needed on the server.
The idea is to move this permanently on the server (file system, cache, distributed cache, database) and tie it to the page with a unique Id, so the client will only be sendind and receiving a bunch of bytes instead 300+ KB.
This is quite a common optimization in ASP.Net, just like the Page Output Cache one and you can find plenty of articles and examples on it. The main "problem" is that most of them resort to writing a base page class and having all the pages inherit from that one, to override the methods that handle the viewstate, but a workaround is infac to to exploit the page adapter (or httpmodule but this is even more complex in this scenario) so you con leave DNN base code intact.

As always I'll keep you notified on my progress on this (as well as on the Output Cahce).

I didn't check yet but I guess that overall it would be always around 300KB as a minimum + the modules you add. I think it's a well worth solution