[eluser]BrianDHall[/eluser]
I suppose kurucu actually kind of brings up the point of the problem with 'premature optimization' - seeking to optimize something you don't know will actually be a problem. It requires a great deal of planning and consideration to implement, and ultimately for most sites will be a local optimization that only works on some pages.
Now if a site is largely static then this is fine, though I wonder if the site is largely static if there shouldn't actually be a system used to write files to an actual html file and just have a cron going through a determining ever so often if any files need updating due to newly added or changed content. Then pages that won't benefit from caching are excluded, or not manually included.
Again though, this might be a useful tool for optimization in theory, but if it is being implemented before its an issue you might be mending a bridge you will never actually cross.
I've yet to ever build an app that turned out exactly like I thought it would in the beginning, and even now I have static pages that could, in a single day, become something that will need to be dynamic.
For my money, if you want to really capitalize on caching enough to make it worthwhile you have a CI system that generates static real .html pages, you have an htaccess system that permits accessing a file directly if it exists (so the .html file doesn't get redirect if it really exists).
Hm, here's a thought thats more in line with the OP - what if you edited the index.php file to check for a cookie and then either served a cached page or static html page, or then proceeded with loading CI? Then the overhead is just a very small 1 page php script to check for the cookie.
