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.