MilliCache is a new full-page cache plugin from MilliPress, a small team of long-time Roots community members. It stores rendered responses in Redis (or any Redis-compatible server — ValKey, Dragonfly, KeyDB) and serves them from advanced-cache.php before WordPress boots. There’s also an Acorn package that drops it into Acorn projects.
4 Likes
Can it be used with the Cache Enabler plugin?
Thanks
@vutruso I’ve answered your question here: Installing MilliCache · MilliPress/MilliCache · Discussion #104 · GitHub
I’ve read the article and I’m basically sold on using this. Some questions that I wish was listed either on the blog post, or on MilliCache’s repo though:
Can it be used with Redis Object Cache? I assume yes?
Edit: Apparently this is mentioned:
The cost is that you need a Redis server. If you already run one for the object cache, you’re ready. Trellis users can easily change the WordPress sites config and then Trellis will provision Redis for you.
What’s the difference between this and FastCGI in practice? This is easier to invalidate manually, is that it?
They answered your first question in the comment above: Installing MilliCache · MilliPress/MilliCache · Discussion #104 · GitHub
MilliCache is a page cache, it doesn’t cache DB queries like Redis Object Cache does. So using both is recommended.
For the second question: something that differs is that FastCGI (at least in trellis) doesn’t flush its cache on actions like a page update (while MilliCache does). It only refreshes its cache based on the duration you’ve set. That’s why they recommend a low cache duration.
What’s the difference between this and FastCGI in practice? This is easier to invalidate manually, is that it?
Yes, easier invalidation is a big part of it — but in practice it goes a bit further than that.
Both FastCGI cache and MilliCache aim to do the same thing: serve a full page without booting all of WordPress on every request. The difference is mostly where the cache lives and how much application awareness it has.
FastCGI cache is web-server-level caching. It’s extremely fast, but usually more blunt: you cache URLs, and purging tends to be URL/path based unless you build quite a bit around it.
MilliCache is application-aware full-page caching backed by Redis. So it can make decisions based on actual WordPress context — posts, terms, templates, blocks, query state, cookies, request patterns, custom hooks, etc.
So in practice, the differences are things like:
-
More precise invalidation instead of clearing broad sections of cache
-
A Rules system to define what should be cached, bypassed, ignored, or purged
-
Better fit for WordPress-specific logic and dynamic setups
-
Less dependence on a specific server stack or Nginx config
-
Easier to distribute/configure as part of the app, especially across different hosting environments
For me, one of the biggest practical benefits is that MilliCache is not just “page cache in Redis”, but a framework for cache decisions. The Rules system makes it much easier to express things like:
-
don’t cache this kind of request
-
ignore these query params/cookies
-
attach these flags to this response
-
purge only pages related to a changed entity
That’s harder to do cleanly with plain FastCGI cache, where you often end up pushing more and more logic into server config.
So I’d put it like this:
FastCGI is great if you want a fast, simple, server-level page cache. MilliCache is more interesting if you want WordPress-aware full-page caching with much more precise control over caching and invalidation behavior.
3 Likes
Seems pretty amazing to be honest. FastCGI not registering when changes are published has always annoyed me.
I’ve tried it out a bit and it seems to work very well. Thanks for making this!
2 Likes