There are a lot of nice cache plugins for WP (even I wrote one a long time ago), but there’s still not one as core functionality.
Microcaching could save a lot of sites out there if they are hit with unexpected amount of traffic.
Read-only archive: https://petitions.classicpress.net/posts/147/full-page-cache-as-core-functionality
Author: Peter Molnar
Vote count: 8
A long time ago I wrote a cache plugin:
WP-FFPC – WordPress plugin | WordPress.org
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).
~ posted by Peter Molnar
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.
~ posted by James Nylen
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.
~ posted by Wells
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
ClassicPress Research · GitHub. Ping me on Slack or the forums to get that set up.
~ posted by James Nylen
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.
~ posted by stefanos82
I’m using this plugin
https://wordpress.org/plugins/wp-ffpc on my websites right now. It’s excellent! And it greatly increased the speed of my websites with ClassicPress
The only sensible way of implementing this at the moment would be to add APCu. But it’s not clear to me why this should be part of core when we have actually agreed to slim core down and make it modular. It’s also quite easy to add an APCu driver as an
This is another thread that should be closed as won’t fix.
Not all websites need caching. For those that do, a plugin can help. Keeping core slim is our goal.
This topic was automatically closed after 3 days. New replies are no longer allowed.