TL;DR:
Introducing MilliCache, a highly flexible WordPress full-page caching solution based on Redis for exceptional speed, easy scalability, and efficient, targeted cache invalidation. Seeking feedback from fellow developers!
What? @vdrnn and I have been working on a new WordPress plugin called MilliCache. We aim to make it the most flexible full-page caching solution for WordPress. So what makes it different from others?
Lightning Fast : In-memory full-page caching using Redis.
Efficient Cache Invalidation : Allows for highly targeted cache clearing, greatly increasing efficiency and flexibility.
Cache Flagging : Supports complex cache logic and selective clearing.
Expired Cache Handling : Regenerates cache in the background without affecting user experience.
Multisite Optimized : Ideal for WordPress Multisite and Multi-Network environments.
Scalable : Works with Redis clusters.
Compatible : Works with Redis Server, KeyDB, Dragonfly, and coexists with Redis Object Cache plugins like WP Redis and Redis Object Cache.
Why?
We have worked on some large-scale projects in the past that were either running horizontally scaled behind load balancers and needed to share the same cache, or were Multisite setups that required a more flexible cache invalidation system based on the usage of specific content. Furthermore, we needed the caching solution to function as a second-layer cache behind edge caches at the CDN. I tried most existing solutions but always encountered limitations that made them inadequate for our needs.
How?
The plugin is currently under active development, and I would greatly appreciate it if some of you could test it out and share your thoughts. Since I am not yet comfortable publishing it publicly, please send me a PM with your GitHub username, and I will add you to the repo .
@evance , @Twansparant & @slowrush thank you for your !
I will be happy to add you to the repo if you want to test it.
However, I will need your GH usernames.
Nice one @philipp! I would love to join the repo, but we don’t currently have Redis in our production stack, so don’t think I’ll be much help with feedback just yet - Redis caching is on our roadmap though, so hopefully we’ll be able to contribute in the near future
@strarsisfragment caching is definitely a feature we want to work on.
However, in its current state it is full page caching that uses the flexibility and power that Redis can offer, and yes, it makes caching in WordPress much more smart.
Especially the flagging of cache entries is a huge benefit.
Take Synced Patterns as an example. Imagine you are editing a pattern that is used on multiple pages. You would probably manually flush the entire cache to make sure the pattern is updated everywhere. However, MilliCache will flag entries that use the pattern (TBA) and automatically update only the cache entries that have changed.
Compared to NGINX microcaching, the similarity is that MilliCache can benefit from short TTL. It will be the perfect choice if you want to use edge caching at a CDN. In this case, MilliCache is the second level cache that handles the first & second level cache entries.
Does this sound interesting? We are really looking for any feedback as it helps a lot to define the next development steps.
Hi Philipp,
would love to get access to this, have just been researching Redis full page caching and this looks like a perfect solution for my needs. My gh profile is manimul.
Thank you @ben for reopening the thread—guessing you saw some GitHub activity again.
After some very busy months, I finally found time to continue working on MilliCache and just released Beta 2 today. This version brings a lot of improvements and takes the plugin several steps forward:
Settings UI (WIP)
Admin Bar integration: instantly clear cache from the Admin Bar.
New React-based “Settings UI” that feels native to WordPress.
Configure cache behavior, Redis connection, and advanced options directly in the Dashboard (Settings → MilliCache).
You can now use either the Dashboard UI or wp-config.php constants—constants always take priority.
Cache management (clear all cache, clear by flag/url/id, view statistics) is now possible via the admin interface, removing the need for manual wp-config.php editing for most tasks.
WooCommerce Support
Tested with WooCommerce.
Cache is automatically bypassed for account, cart, and checkout pages.
Cached content (e.g. product pages) works even if the cart is not empty.
Cache Management Enhancements
Clear cache by post ID, URL, or flag—via UI, CLI, or PHP.
Wildcard support for clearing groups of entries or network-wide caches.
Enhanced API and CLI commands, e.g. to support multiple targets to clear in one go.
Other Notable Improvements
New REST API endpoints for managing settings and cache.
The README has been significantly expanded and rewritten.
Improved Playwright test workflow and performance benchmarking in CI.
Improved multisite and multinetwork cache flag logic.
Improved debugging UI with cache status and diagnostics.
This is a great time to test MilliCache and provide feedback—it helps immensely in focusing development. Even if you don’t test it directly, we’d love to hear what matters most to you in a full-page caching plugin. What cache critical plugins do we need to test? What would make your work easier or your sites faster?
Performance Snapshot (CI-based test)
Apropos fast: We’ve added a simple performance benchmark to our CI pipeline to compare MilliCache with other popular plugins. These numbers are rough and not load-tested—but they do give a general sense of where things stand:
Plugin
timeToFirstByte
largestContentfulPaint
lcpMinusTtfb
wpDbQueries
wpMemoryUsage
wpBeforeTemplate
wpTemplate
wpTotal
no cache
47.00 ms
124.00 ms
76.10 ms
27
7.43 MB
349.76 ms
26.94 ms
376.70 ms
millicache
4.70 ms
80.00 ms
74.80 ms
29
5.73 MB
32.87 ms
22.79 ms
55.66 ms
breeze
10.00 ms
84.00 ms
77.30 ms
37
5.79 MB
55.22 ms
20.96 ms
76.17 ms
cachify
18.90 ms
92.00 ms
73.80 ms
31
5.64 MB
24.69 ms
22.81 ms
47.49 ms
cache-enabler
43.70 ms
120.00 ms
74.50 ms
28
5.50 MB
29.61 ms
21.63 ms
51.24 ms
wp-fastest-cache
44.70 ms
120.00 ms
74.70 ms
31
5.54 MB
29.36 ms
20.05 ms
49.41 ms
wp-super-cache
44.00 ms
116.00 ms
73.40 ms
29
5.58 MB
40.82 ms
20.07 ms
60.88 ms
Test: Each plugin loads the same page 15 times, and the average is taken.
Would be interested in taking a look too sounds awesome! username: oxyc
invalidation sounds a bit similar to what we do GitHub - generoi/sage-cachetags. We rely on manually tagging views/entities though and dont use redis, rather http headers and proxy caches.
also if wp super cache is set up to serve html files straight from the webserver there are 0 db calls (or even php processes). invalidation is very lacking of course.
@oxyc it is, and I would have loved to have seen this solution before. Your approach with headers and proxy invalidation looks super clean and elegant. Very nice one, as are many of your other packages.
We’ve thought a lot about the fact that PHP is still involved.
But assume that for most sites that’s totally fine — Redis is fast, and PHP doesn’t do much work on a cache hit. We can still bypass the DB and WordPress entirely.
For larger setups with a lot of traffic, we already use MilliCache as a second-layer cache, with a CDN (like Cloudflare or Bunny) in front. With that edge cache setup most traffic never hits the origin server at all and the we can benefit from the globally distributed cache with super-fast response times. MilliCache also handles the cache invalidation at the CDN.
However, this is something we will port over once the core functionality is stable.
I have added you to the GH repo. Would love your thoughts if you try it out.
Quick follow-up: We’ve now finally launched MilliCache as an open-source WordPress plugin!
MilliCache is a Redis-based full-page cache for WordPress, built with a strong focus on control over cache behavior and invalidation.
For Acorn-based projects, there is also an Acorn MilliCache package, which adds support for caching Acorn routes.
Alongside it, we built MilliRules — a rules engine we use for caching strategies, but also for general site logic (conditions & actions → rules). The Acorn MilliRules package adds Acorn-specific conditions and actions on top of the built-in PHP and WordPress ones, and custom additions are straightforward:
This seems to be exactly what I am looking for. Currently using WP Rocket for full page caching which has served me good but it is becoming booated with features that I don’t need. I also like the developer centric approach that MilliCache seems to have as opposed to a plethora of settings and stuff in the admin area.
I can’t find anything on warming/pre-rendering in the documentation. If I haven’t missed anything I will have a go at building something that warms the cache based on the sitemap since in my most current project, most of the pages are ”virtual” (not WP posts but based on data from en external API) which will be added to/roved from the sitemap as needed.
Thank you @folbert! It’s great to hear that it will be useful to you.
I can’t find anything on warming/pre-rendering in the documentation. If I haven’t missed anything I will have a go at building something that warms the cache based on the sitemap
We are already working on MilliCache Pro, which will include modules such as deeper integration with FSE and the Block Editor. The cache warming/pre-rendering module has already been developed and we are considering releasing the first version very soon, with further modules added as they are ready. Would that be of interest to you?
I tested it in an environment where Redis is only exposed via a Unix socket (/tmp/redis.sock). MilliCache currently assumes a TCP connection, so it was not able to connect out of the box.
Also, in some environments commands like CONFIG are disabled, which causes the status check to fail even though Redis itself is working.
It would be great if Unix socket connections were supported and restricted commands handled more gracefully, as that would improve compatibility with more hosting setups.
After adjusting for that locally, performance has been excellent so far.
!
sounds awesome! username: oxyc
Your approach with headers and proxy invalidation looks super clean and elegant. Very nice one, as are many of your other packages.
