Yes, this is exactly what is happening again and again. I remember when mSQL (and later MySQL)+PHP was all the rage and everybody was writing CMSes with it (could be late 90s) and people routinely complained about efficiency, it occurred to me: since these are mostly reads, and writes are quite rare, why don't we regenerate the necessary elements only on write, and not whenever a user visits a page? I created a simple proof of concept with multiple themes and it worked perfectly. Fast forward 15 years and static site generators were all the rage. I believe they will resurge again around 2030.
I took that approach with a high traffic site about 10 years ago. The property was mostly write once content from official staff writers with social engagement, comments, follows and light user generated content, etc. It was built originally with Ruby on Rails and over time had lots of layers of caching. Eventually I moved to a system of partial caching which was stored on the file system and nginx would use SSI to reassemble the partials into complete pages. All dynamic content would be loaded secondarily via javascript with mustache templates and lots of in memory json caches. It would even rsync the file system across a handful of hosts which turned out to be a pain in the butt - then distributed file systems were probably less mature than they are now so I never ended up implementing but did much research.
Funny, I think probably all of the above would be trivial now on AWS or Cloudflare.
