I've had this same problem myself, you can indeed get around some of it by using javascript but I'd rather not use JS for something unless I really have to. This is because you often end up with a slower site to the end user as you end up serving extra JS files (sometimes including jquery) not to mention noscript users etc.
I think the problem is that stuff that starts being pretty static can often end up getting slowly more dynamic and at some point you have to re-engineer it which becomes a pain so it's easier to plan around this from the start.
I took over a project which used static content to serve everything which included a lot of fwrite() PHP calls. As this got more complicated we ended up cache invalidation type issues where there was a hierachy of content that needed to be re-written back to various files every time something was changed on the site.
This meant that saving changes to the site became incredibly slow as we often erred on the safe side which meant we ended up re-writing some things multiple times, also the code that checked files to see which parts needed to regenerate became exponentially more complex.
In the end I just generated everything from the DB and used memcache in a few select places, performance for serving content was about the same as serving the static files, the code was much cleaner (which helped make performance better in the long run) and usability from the content administrators POV was much improved.
You should always aim to be serving your most common content directly from RAM anyway, so whether this is from the kernel's pagecache or memcache doesn't matter so much, you can probably solve this problem using clever proxying too.
I think the problem is that stuff that starts being pretty static can often end up getting slowly more dynamic and at some point you have to re-engineer it which becomes a pain so it's easier to plan around this from the start.
I took over a project which used static content to serve everything which included a lot of fwrite() PHP calls. As this got more complicated we ended up cache invalidation type issues where there was a hierachy of content that needed to be re-written back to various files every time something was changed on the site. This meant that saving changes to the site became incredibly slow as we often erred on the safe side which meant we ended up re-writing some things multiple times, also the code that checked files to see which parts needed to regenerate became exponentially more complex.
In the end I just generated everything from the DB and used memcache in a few select places, performance for serving content was about the same as serving the static files, the code was much cleaner (which helped make performance better in the long run) and usability from the content administrators POV was much improved.
You should always aim to be serving your most common content directly from RAM anyway, so whether this is from the kernel's pagecache or memcache doesn't matter so much, you can probably solve this problem using clever proxying too.