Cloudways cache settings, explained without the jargon

Cloudways gives you two caching layers to control from the panel: a full page cache that runs on the server itself, and an object cache, available as a Redis add-on, that keeps repeated database results in memory. For a standard WordPress site the defaults are close to right, and the settings that deserve your attention are few: page caching switched on, the right pages excluded from it, and purge behaving when content changes. This guide explains each layer in plain terms, because settings you changed with understanding are settings you can diagnose later.

Full page caching, at server level

When a visitor requests a page, the server normally runs the whole stack: PHP loads WordPress, your theme and plugins initialise, queries hit the database, and the finished page goes back. The Cloudways full page cache, Varnish, sits in front of all that. The first visitor triggers the full build, the server stores the result, and every subsequent visitor gets the stored page without PHP being woken. Anonymous traffic, which is most traffic on most sites, becomes nearly as cheap to serve as a static file.

Because this cache lives on the server rather than inside a plugin, it is indifferent to what your plugins are doing. It keeps working through plugin conflicts and plugin updates, and it is the single highest-impact performance setting on the platform.

Varnish, Breeze, and the confusion between them

Breeze, the caching plugin Cloudways preinstalls, causes understandable confusion: two caches, from two directions, on one site. The division of labour is simple. The server-side cache handles whole pages. The plugin handles the WordPress-side work: asset minification, browser cache headers, and clearing its own cache when you publish or update content. The pair are built to work together.

The mistake is stacking a second full-page caching plugin on top, which leaves you with two caches invalidating on different signals and a site that intermittently shows stale content for reasons nobody can reproduce. If you insist on a different caching plugin, work out exactly which of its features overlap with what the server already does and switch the overlaps off. Most sites should stay with the built-in pair and spend the attention elsewhere.

Purge, the control people get wrong

Purging drops stored pages so the next visitor rebuilds them fresh. There are purge controls at both levels: the panel clears the server-side cache per application, and Breeze clears its own cache when content changes. Both directions fail in interesting ways. A site that never purges shows stale content: you update a page, reload, see the old version, and spend an unhappy afternoon discovering cache invalidation. At the other extreme, purging everything for every trivial change is harmless on a small site and wasteful on a busy one, because a full purge puts every visitor back on the slow path until the cache refills. Purge what changed, keep the panel's per-application purge as the emergency override when you need certainty, and resist the urge to build a habit around it.

WordPress versus WooCommerce

For a plain WordPress site the defaults are sensible: pages cached, the admin and logged-in sessions outside the cache, purges wired to content changes. Leave them alone.

WooCommerce changes the rules. Cart, checkout and customer account pages must never be served from a page cache, because their content belongs to one specific visitor, and your cart is yours. When a cache leaks onto those pages you get the horror stories: carts showing someone else's selection, checkout totals carried over from a previous session, account pages rendered logged-out. Check that the exclusions cover cart, checkout and my-account, and add exclusions for any page with personalised content, a quote form that retains state, a page that greets a logged-in visitor by name. Then test as an actual shopper, because an exclusion that looks right in a settings screen and fails in a browser is a genre of bug all its own.

WooCommerce also raises the value of the object cache, since so much of its traffic, cart updates and logged-in shoppers, cannot use the page cache at all.

The Redis object cache

The object cache answers a different question from the page cache. The page cache skips building the page entirely; the object cache makes building it cheaper when building is unavoidable, by holding the results of repeated database lookups in memory. You feel it in wp-admin responsiveness and in every request that page caching cannot touch.

On Cloudways, Redis is a server add-on. Enable it, confirm the application is genuinely wired to use it, since the add-on running beside the app achieves nothing on its own, then watch admin for a few days. On a quiet brochure site the difference is small enough to skip. On a WooCommerce store or a busy membership site it is one of the best-value toggles on the platform.

When to leave everything alone

Cache settings share an uncomfortable property: every exclusion and toggle you add is a new way to be wrong, and the failure usually stays silent until a customer mentions it. With no symptom on the table, no stale pages, no wrong cart contents, no slow admin, the defaults are doing their job. Change one thing at a time, for a reason you can name, and verify against the symptom that motivated you.

Cache behaviour is also just one layer of WordPress performance. The wider order of operations, hosting and page caching first, images, database and plugins next, CDN last, is laid out in the WordPress speed guide. And if you have arrived here while still choosing a host instead of tuning one, the full Cloudways review covers what the platform does well and where it annoys.