I guess the site is served using PHP.
In my experience php is fast enough until you start generating lots of garbage. It seems it wasn't really designed to garbage collect at all, but to rely on the per-request cleanup.
We should really stop pretending that the garbage collector is the problem with langauges. The collector isn't the problem, your garbage is the problem.
[Not that I'm a proponent of PHP, though it does make popping shells far more fun.]
Now, the approach PHP takes is fine for the original vision of the language. It even works great.
But languages designed for long running processes often have some sort of mechanism for dealing with that situation explicitly. Like the `NSAutoreleasePool` in Objective C. In C++ you might build your own custom slab allocator.
I'd say the garbage collector is one of the problems with PHP. Then again, if you run into it, PHP might not be the right tool for that particular job.
This means that there is a conflict between performance and having a well structured object oriented framework.
Demand loaded classes and byte code help a lot with that: http://www.yiiframework.com/performance/
Best would be a model where a persistent process handles multiple requests concurrently, but that is not normal for PHP. So you need to make sure that all the libraries you are using are not leaking, have a nice db connection pool, and write a PHP framework that handles concurrency. Might as well use a better language at that point :-)
What do you need a 'well structured object oriented framework' for? You're going to build up a huge object graph in memory, to output some HTML, and then throw away all the objects at the end of the request. Nobody is going to see your beautiful object tree, so don't bother. A blog entry page should be super simple.
header, title, content, comments, recent comments, footer.
Header and footer are dead simple echos of the boilerplate, maybe replace in the html title or something. Read the title and content from disk[1]. Have another data file for all your articles for the index page.
I prefer not to have comments on my blog, but if you must, you can put them in a database; limit to something like 100 or 1000 comments per article (because really) and limit threading, and it's going to be pretty quick to query them (make sure your webserver is doing reads from a database in the same metro area, if not on the same box).
Recent comments is across all blog entries; I would probably add a index on the time in the comments table and just select 2 from there; you could union that into the earlier comments query if you don't want to make two round trips to the database.
You don't need to do this with concurrency, each page load has barely anything to wait for, so more threads doesn't help throughput. Run enough php workers (php-fpm, or apache children if you're using apache_mod_php) to keep your cpu busy, and you're golden.
[1] There's four articles on this blog -- it doesn't need a database. PS run php as a user that can't write anywhere on the disk, and push the blog entries and the summary datafile with another user.
Edit to add: If you skip comments (or outsource to disqus or some other comments w/ javascript platform), you can make the whole site just static html, and leave PHP at home. OTOH, these guys are running Wordpress, because they like frequent security updates?
PHP ships with an opcode cache built-in (and at least on every distro I've seen, enabled by default) since PHP 5.5 that keeps the compiled bytecode in shared memory