Blogs, as most current web applications, need to perform some caching of their pages on the server, in order to reduce webserver load and respond faster to client requests.
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.
We actually think of it as "baked on demand"... but regardless of what we call it, we think it's not a satisfying solution!
With b2evolution, we have done some experiments caching blog homepages, which is already enough to significantly reduce server load and response times, since a very large portion of requests, including first visits, start with the home page.
However, this really makes the home page (or other pages we might apply this to) too static for many uses:
- We want to log some stuff in realtime
- We want new user comments to show up instantly (or at least, with a very short delay)
- And most of all: We want pages 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 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 everytime.
And there you have it: performance and functionality.
Of course, it's also much more complex to implement than any other caching mechanism... BUT, you can count on b2evolution to implement something like this in the future!