As a performance boost, investigate caching of pages/API requests that can be served as static content

Opening this issue per recent conversation with Jim (but something similar had been suggested in the past as well).
We have certain pages that, under some circumstances are both a) expensive to render and b) are guaranteed to have identical content between repeated calls. So it should be possible to render such pages once, then serve cached copies.
Prime examples I can think of are the published dataverse and dataset pages, as served to guest users. (Not sure it can be easily done with logged-in, non-guest users, even for published objects - it gets complicated there fairly quickly).
Even with guests and published materials, it's unlikely to be entirely trivial - as most of our pages are not single chunks of content that are easy to save, but have some dynamic content/partial submits, etc. Plus, if we can only do it for guests, it'll take some non-trivial mechanism for determining when to use cached content, and how, and when to serve full pages. (Not something that can be implemented with simple Apache rewrite rules - I don't think?).
Still, it should be worth investigating. And there's a chance there are some off the shelf solutions already available.

Start by investigating how published dataverse and dataset pages are rendered for guest users, focusing on which responses are identical between requests and which dynamic content or partial submits prevents caching. Compare available caching solutions and define how cached content would be selected, refreshed, and bypassed for logged-in users. Done means a feasible approach and scope are documented.