Blogs, as most current web applications, need to address the server-side caching issue in order to reduce webserver load.
It looks like most people are quite happy with caching static versions of their pages for some defined amount of time. This method has often been called something like “half-baked/half-fried” in reference to the long running baked (static) versus fried (dynamic) discussion.
I’d actually call it “baked on demand”… but regardless of what name we use, I would not be satisfied with this.
I have actually done some experiments caching my blog homepages which is enough to significantly reduce load, but this really makes them too static for me. I do want to log some stuff in realtime, I do want new user comments to show up instantly, and most of all: I do want the page to be customized for each user: display new posts since last visit, display his personal choice of categories, etc… Caching a whole page for every possible combination seems plain stupid. (And it is! :» )
Actually, the only smart caching mechanism one can be satisfied with in high-end web-applications is block-caching. As a matter of fact, a web page can actually almost always be considered as an assembly of different blocks. Some are static, some are dynamically updated several times a day, some are related to the user himself and some are so dynamic they change everytime the page is displayed, no matter what! By caching each of these blocks individually when it makes sense and rebuilding only those necessary at a given time, you can then reconstruct your whole page dynamically significantly faster than if you had to reconstruct all blocks from scratch every time.
And there you have it: performance and functionality. Yeah, Okay, I know… it’s also much more complex to implement than any other caching mechanism… ;D