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.
Checkout, admin and member pages can never come from a page cache, and this is what stops them being slow.
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.
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.
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.
If the cache is unreachable the site should get slower, not break. Lookups fall through to the database rather than raising an error page.
Several sites sharing one Redis instance need separate prefixes, or one site's flush clears another's cache and both get mysteriously slow.
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.
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.
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. |
Every plan includes free migration, daily backups, SSL and 24/7 support.
Move the site across — migration is free, cache sizing reviewed.