Lately I have been working on a legacy rails project which had page caching in place. Here are a few points I think are takeaways for me from my experience with it:
1) Page caching is useful on pages which have more or less content related to same resource. If you have multiple kind of unrelated content loading on the page which expire at different times, then the page cache may not be of much use. And you may be clearing out the entire cache for that page unnecessarily when one piece gets updated thus affecting your performance.
2) When page caching comes into picture you can’t have user specific code in the server side code for those pages. Particularly, beware of putting in cookie checking code on the server side. It should probably not be there anyways, but yeah if you have it for some reason, do not forget that you are using page caching. One may argue that why would one use page caching for user specific content anyways, but on pages where extremely minimal stuff is user specific, it is very easy to forget that there is page caching in place. And then you will land up having pages cached in a state based on the first viewer of that url and all other users would see that view. 😦
3) Do not depend only on ui interfaces to clean up your page cache. Admins who don’t understand it completely will keep clearing your cache every now and then and your pages would perform poorly. Have sweepers for observing content and deleting the corresponding cached pages automatically (which is the natural way for page caching invalidation 🙂 ) rather than admins taking a guess that this particular page cache needs to be cleared when I update this content.
Page caching can lead to a lot of performance boost if the above points are kept in mind since then the time required for the request to process would be just the time required to send back the html. And extremely expensive requests would start serving almost in the same time as normal requests.
For more details on page caching and dynamic content on cached pages see