[eluser]kurucu[/eluser]
It sounds like a great idea, Xeoncross. I'd personally not worry until the site was large enough to be problematic, but see the point completely. What's more, in addition to your performance sentiments, doing it early will likely save a lot of time when it becomes later necessary.
What I would say is that understanding of the site in question would be important. If, for example, a public blog is commented on every few moments then you either give up caching, as creating and destroying the cache becomes a burden, or only update the cache every 10 minutes. Deciding on matters like that would depend on the system in question. Also, with some knowledge of the session handling of the implemented system, adding new cookies may not be necessary as there might be nice easy hooks to grab hold of already.
Of course the implementation you hinted at is possible, but I would argue that after all this it might only be relevant to some sites/pages. I've stuck to partial caching so that the dynamic content stays dynamic and the relatively static content is cached (general page elements, blog content etc). I wouldn't want pre-caching of the whole page to break things like form validation and flash messages.
Essentially, if you're escaping your framework (and therefore probably business logic of your site, as it was written within the framework) either your framework is too heavy or it has been misused.
Wow. What a conflicted post I've written!
