1. Stash key-value pairs in signed cookies (salt + text + sha1 should be fine; HMAC is even better-- I prefer a variant of HMAC where I concatenate the client's IP address onto the first hash before hashing again with the second key).

1a. Note that this only goes for key-value pairs you don't mind the user seeing, but want to keep tamper-proof. Real secret stuff still needs to be handled server-side.

2. Display them javascriptically, and only verify/change things server-side on login or POST. This lets you serve most pages as cached, static HTML!

2a. So if my username cookie is "[some 40-byte salted sha1hash]icky", then, client-side, I could change the username or the hash, and the page's javascript would display the new username for me (blindly chopping off the first 40 bytes that form the hash), but if I tried to post, then the server would detect the tampered cookie, and log me out. [Tampering with the display-name client-side is something you can already do with the Firebug or Web Developer plugins, so this really doesn't pose a problem].

3. When a POST happens, just regenerate the cached page that it dirtied, and dynamically serve it back to the poster.

4. That's it! You now have turned nearly all of your read-only requests into a static, cached page GET, which you can let Apache take care of without even hitting your application server.