LiteSpeed Cache hosting where one layer is in charge.
A caching plugin and a server cache both believe they own the response. When they disagree, you get a stale page that clearing the plugin cache does not fix.
Two caches is one too many.
The hardest bugs in WordPress performance come from layers that cache the same thing under different rules.
A decision about who owns the response
Either the plugin serves cached HTML or the edge does, and the other steps back. Left undecided you get double-caching, where the outer layer holds a copy the inner one has already replaced.
Purges that reach every layer
Clearing from the plugin has to invalidate the edge as well, or an editor sees the change and visitors keep the old page indefinitely.
Exclusion rules written once
Cart, checkout and logged-in bypasses exist in both layers. Written twice they eventually disagree, and the one that forgets is the one that leaks a session.
Optimisation left to one place
Minification and combination handled by both the plugin and the platform produces broken assets. It is enabled in one layer only, deliberately.
Recover from an over-aggressive rule
A cache rule that caches something personal is a disclosure. Backups and a quick rollback path matter more here than the speed gain did.
Stale pages nobody can clear.
The classic symptom is an editor who has purged everything they can find and a visitor who still sees last week's homepage. That is two caches, not one broken one.
- Ownership of cached HTML decided explicitly
- Plugin purges propagate to the edge
- Bypass rules maintained in one place
- Asset optimisation enabled in a single layer
Fast is easy. Fresh is the problem.
Both layers will happily serve a page in milliseconds. What matters is whether that page is the one you published.
What we change for caching plugins
Nothing here makes the site faster. It stops two fast things from producing a wrong answer.
| Setting | What we do | Why |
|---|---|---|
| HTML cache ownership | Assigned to one layer with the other standing down | Two layers caching the same response means the outer one can hold a copy the inner one has already invalidated, and no purge available to the editor reaches it. |
| Purge propagation | Plugin purges wired through to the edge | An editor clearing the plugin cache and seeing their change is the worst case, because it convinces them the problem is fixed for visitors too. |
| Bypass rules | Cart, checkout and logged-in exclusions defined in one place | Maintained in both layers they drift, and the layer that forgets an exclusion is the one that serves somebody else's session. |
| Asset optimisation | Minification and combination enabled in a single layer | Two systems rewriting the same CSS and JS produces broken output that only appears on some pages, which is close to undiagnosable. |
| Rollback path | Kept short for cache rule changes | A rule that caches something personal is a disclosure rather than a performance regression, so reverting quickly matters more than the gain. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
I purged the cache and visitors still see the old page. Why?
Should I use a caching plugin if the host already caches?
Can I let both handle minification?
Where should cart and checkout exclusions live?
One cache, always fresh.
Move the site across. Migration is free, cache layers sorted out.