full page cache as core functionality

>Microcaching could save a lot of sites out there if they are hit with unexpected amount of traffic.

The best way to "save" such sites is to handle caching from outside WP/CP by using something like Varnish or Litespeed Cache. I would need a much more detailed explanation of what you have in mind before I could agree that page caching should be part of core.

A long time ago I wrote a cache plugin: https://wordpress.org/plugins/wp-ffpc/
While it can utilize memcache(d) and some nginx rules to completely bypass PHP, the most efficient way was to use APC. At that time APC was quite widely used, and has a user cache besided the code cache. Nowadays there's opcache, and, if installed by hand, APCu, so sadly that plugin is not viable for widespread use, and it never had the code quality to even be mentioned as core functionality.

However, it taught me a lot of things, mainly the fact that external caches - nginx, varnish, etc - are quite dumb. They never serve x-pingback headers (though this is about to die out), real last modified dates, etc. They also require a good understanding of the server side, which most users don't have, and, on shared hosting, it's not even an option.

I still believe caching should be part of core, but it's a very, hard, tricky topic, especially when it shouldn't rely or require external components.

Filesystem level caching is nice, because all OS level cache will slurp it in, but it can be harsh on the drive. If a tmpfs-like in-memory fs is available, that could be used instead.

(I'm just brainstorming; as mentioned, I don't have a ready solution/proposal).

>on shared hosting, it's not even an option.

My host (Lightningbase) certainly does provide it, and they are very good at knowing how to configure it too.

It'd be great to add more caching as part of core, but I agree it's a tricky topic. Making sure the caching is actually an improvement is not trivial if you have a slow filesystem or lots of poorly-tuned DB traffic. Locking can also be a problem (I haven't run across a server without working flock for example, but I hear they are out there.)

Making better use of the built-in object caching functions (and still requiring that memcached or something similar be available) might be a reasonable path here.

PHP's request cycle is very much isolated from other requests, and WP/CP are fully dynamic platforms by default. These two facts combined mean that adding an external layer for caching is by far the easiest way to make it work well.

Unfortunately, I agree that this would be quite challenging to implement in a way that doesn't cause massive headaches for a significant portion of users. I've noticed that APC(u) is increasingly available on shared hosts, so perhaps providing an object cache driver for APCu within CP is a more realistic first step.

As usual, if someone wants to start on an experimental implementation of this, or already has code to contribute (we love when that happens!) then I will create a repository under https://github.com/ClassicPress-research. Ping me on Slack or the forums to get that set up.

I have once seen how PrestaShop works behind the scenes and one thing that fascinated me is that it comes with a mechanism that generates cached content upon save as administrator user and serves that upon need.

Those who have worked with NGINX's microcaching, it resembles that but saved as part of the hosting directory of website.