Redis object cache hosting for everything a page cache cannot help.
Page caching serves the pages nobody is signed in for. The object cache is what makes the rest of the site quick, and it is the layer nobody sizes.
The layer under the uncacheable.
Checkout, admin and member pages can never come from a page cache, and this is what stops them being slow.
Memory sized for the working set
Too small and the cache evicts entries faster than they are reused, which is worse than no cache because you pay the write cost and never get the read. Capacity is set from what the site actually keeps asking for.
An eviction policy that was chosen
The default policy refuses writes when memory is full rather than discarding old entries, which turns a full cache into errors. It is set to evict least-recently-used instead.
Connections that are not reopened per request
Opening a connection on every page load adds a round trip before any work happens. Connections persist, so the cache is a lookup rather than a handshake.
A site that survives Redis being gone
If the cache is unreachable the site should get slower, not break. Lookups fall through to the database rather than raising an error page.
Keys that do not collide between sites
Several sites sharing one Redis instance need separate prefixes, or one site's flush clears another's cache and both get mysteriously slow.
A cache that is too small is a cost.
The failure nobody notices is thrash: entries written, evicted before reuse, and written again. The hit rate looks plausible and the site is doing extra work for nothing.
- Memory sized from the actual working set
- Eviction policy set to discard rather than refuse
- Connections persisted across requests
- Fallback to the database when unreachable
Where the object cache earns its place.
The measurement is a page that can never be cached - a dashboard, a cart, an admin screen - because that is the entire point of this layer.
What we change for the object cache
Every row here is a default that is wrong for WordPress specifically.
| Setting | What we do | Why |
|---|---|---|
| Memory allocation | Set from the measured working set rather than a round number | An undersized cache evicts entries before they are reused, so the site pays the write cost of caching and never collects the read benefit. |
| Eviction policy | Configured to discard least-recently-used entries | The stock policy rejects new writes once memory is full, which converts a full cache from a performance ceiling into application errors. |
| Connection handling | Persistent rather than opened per request | A fresh connection per page load adds a round trip before any cached value is read, which on a fast query is most of the cost. |
| Unavailability behaviour | Falls through to the database rather than erroring | A cache is an optimisation, so losing it should make the site slower and not replace it with a fatal error. |
| Key prefixing | Namespaced per site | Sites sharing an instance otherwise collide, and one site flushing its cache silently empties another's. |
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.
How much memory does the object cache need?
What happens if Redis goes down?
Why is my hit rate high but the site still slow?
Can several sites share one Redis instance?
Make the uncacheable pages fast.
Move the site across. Migration is free, cache sizing reviewed.