Breeze Cache on Cloudways: FAQ Guide to Caching, Purging & Optimization

Breeze is Cloudways' built-in caching plugin, designed to work alongside server-level Varnish and CDN layers like Cloudflare to speed up WordPress sites.

Because these three systems interact, and sometimes behave differently from one another, questions often come up around how caching actually works, when it clears, and how to fine-tune it for specific pages or content types.

This FAQ-style article walks through the most common questions about enabling and verifying Breeze's cache, purging behavior across Varnish and Cloudflare, excluding dynamic content, handling query strings, mobile caching, and troubleshooting, so you can configure Breeze with confidence and keep your site both fast and accurate.

Go to Settings > Breeze in your WordPress admin panel, click the Basic Options tab, check the box next to Cache System, and click Save Changes. This turns on Breeze's core page caching, which is the setting everything else in this subsection builds on.

Instead of WordPress rebuilding a page from the database and running PHP on every single visit, Breeze stores a static, ready-to-serve version of the page once it's generated. Repeat visitors get that stored copy directly, which cuts server processing time and speeds up load times, especially under traffic.

Visit your site, right-click anywhere on the page, and choose View Page Source. Breeze inserts an HTML comment in the source code confirming the page was served from cache. If that comment is present, caching is active for that page.

One-Click Optimization does not enable the Cache System. All three plans (Standard, Advanced, Expert) bundle file and asset-level settings, things like Gzip compression, minification, lazy loading, and file combination, but page caching itself has to be turned on separately in Basic Options.

The one exception worth flagging is Browser Cache, which is included in the Standard plan and does relate to caching, though it's a different mechanism from full-page caching. Don't assume clicking a One-Click plan puts your site into a fully cached state.

In Basic Options, under Cache Logged-in Users, Breeze exposes a separate toggle for each standard WordPress role: Administrator, Editor, Author, Contributor, and Subscriber. Turn on the roles you want cached and click Save Changes. This is useful for membership or community sites, where you may want caching enabled for lower-privilege roles like Subscriber, but left off for Administrators or Editors who need to see live, uncached content while managing the site.

Log in as a user with the role you enabled, then view the page source the same way you would for anonymous caching. If the Breeze cache comment appears while you're logged in as that role, caching is active for it. Repeat for each role you've enabled, since each one is controlled independently.

Clicking Clear Cache on a specific post triggers three different responses at once:

This is intentional. Varnish and Cloudflare sit in front of WordPress and don't have the same page-by-page awareness that Breeze does, so a full purge at those layers is the safest way to guarantee freshness.

Breeze, on the other hand, can target just the changed post, which means the rest of your site's cached pages stay warm instead of getting wiped and rebuilt unnecessarily. The net effect is that your update shows up everywhere it needs to, without a full-site cache cold start.

Yes. Clicking Save Changes anywhere in Breeze's settings also triggers a purge request, so you don't need to separately clear the cache every time you adjust a setting.

Auto Purge Varnish is a setting in the Varnish tab. When enabled, Breeze automatically clears the Varnish cache whenever you take actions like publishing a new post or page, or adding a comment. It also covers broader content changes, including updates, deletions, and theme or plugin modifications. Cloudways recommends keeping this enabled at all times, since disabling it means Varnish won't know when your content has changed.

Go to the Varnish tab and click Purge Varnish Cache. This clears the entire Varnish cache instantly, which is useful after a bigger change, like a theme switch or a design overhaul, where you want every visitor to see the new version immediately.

In the Advanced Options tab, use the Never Cache These URLs field. You can enter exact URLs or use a wildcard pattern to exclude a whole group of pages, for example a specific product category: http://yourdomain.com/shop/category-1(.*). This is commonly used for dynamic content you never want served from a static cache.

Yes. If you're running WooCommerce, the Cart, Checkout, and My Account pages are excluded from Breeze caching by default. No manual setup is needed for those specific pages.

Visit a page that should be excluded and view its page source. There should be no Breeze cache tag present. For comparison, visit a page that isn't excluded. It should show the cache tag. Seeing that difference confirms the exclusion is working as expected.

No. Out of the box, Breeze does not cache URLs that include query strings, things like ?model=mercedes or ?country=RO. These are treated as dynamic by default and bypassed unless you configure otherwise.

In Advanced Options, use the Cache Query Strings field to list the specific parameter names you want Breeze to cache, for example country and tester. Once added, pages using those parameters can be cached rather than bypassed.

Breeze creates a separate cache file for each unique combination of the parameters you've told it to track, and it ignores any parameter you haven't listed. For example, if country and tester are set to be cached:

This lets you cache meaningfully different versions of a page while not fragmenting the cache over parameters that don't actually change the content, like tracking tags.

Varnish is a server-level cache that Cloudways pre-installs and pre-configures. Breeze's Varnish tab gives you a way to manage that cache from inside WordPress, mainly by controlling when it gets purged. You don't strictly need Breeze for Varnish to function, but using them together is recommended, since Breeze is what tells Varnish when your content has actually changed.

Without Breeze (or an equivalent plugin), Varnish has no way to detect that WordPress content has been updated. That means it may keep serving an outdated version of a page until its cache naturally expires, with a default TTL of 4 hours, or until someone manually purges it. In practice, this can mean visitors see stale content for hours after you've made a change.

Go to Settings > Breeze > Varnish. You'll see the Auto Purge Varnish toggle, the Varnish Server field (pre-filled with your Cloudways server's IP, no changes needed), and the Purge Varnish Cache button for manual purges.

When your site uses Cloudflare CDN, Breeze can clear Cloudflare's cached files directly from your WordPress dashboard whenever content is updated. This means visitors get the latest version of your site without you needing to log into Cloudflare separately to purge it yourself.

If you're using Cloudflare Enterprise, Breeze offers 1-click integration with no special configuration required inside Breeze itself. It's designed to work out of the box for that tier.

For Pull Zone-based CDNs, go to the CDN tab in Breeze, check Activate CDN, and enter the CDN's root URL (the CNAME) from the Pull Zone you created with that provider, for example a KeyCDN zone URL or a CloudFront distribution domain. Once connected, your static assets like images, CSS, and JavaScript are served from that CDN's edge network instead of directly from your server.

Go to the Tools tab in Breeze and click Download Settings. This saves your current configuration as a .json file to your computer.

In the Tools tab, click Choose File, select the .json configuration file you exported earlier, then click Upload File and Import Settings. Breeze applies the imported configuration immediately.

If you manage several WordPress sites, importing a saved configuration saves you from manually rebuilding the same cache setup on each one. It also keeps caching behavior consistent across sites, which matters if you're troubleshooting an issue or want predictable performance across a whole portfolio of sites rather than a one-off setup on each.

Yes. Breeze can store a separate cached copy for desktop, tablet, and phone. That way a phone does not receive the desktop HTML, and a desktop visitor does not receive the mobile HTML.

This is optional. If Mobile Cache is off, every device uses the same cached page.

Go to Settings → Breeze → Basic Options → Mobile Cache.

On a new install this option is On.

When Mobile Cache is On, Breeze detects the visitor’s device and saves the page in a different cache file:

When the same URL is opened again, Breeze serves the file that matches that device.

When Mobile Cache is Off, there is no device prefix. Desktop, tablet, and phone all share one cached file.

Breeze caches HTML, including any nonce that was on the page when the file was saved. An expired token can break forms for later visitors. Breeze does not cache POST submits, AJAX, REST, or WooCommerce cart, checkout, and My Account. Refresh cached page parts will not replace forms or nonce fields. For any other form page, add it to Never Cache URL(s), save, and purge cache.

You can temporarily disable Breeze caching to troubleshoot issues. For this, go to Settings → Breeze → Basic Options, uncheck Cache System, Save, then Purge All Cache.

On the Cloudways platform, additionally purge Varnish (and Cloudflare if it is active on your account). Test the page in a private/incognito window. To test one URL only, add ?nocache=1 or put the page in Never Cache URL(s). Remember to turn the Cache System back on when you finish.

On Cloudways, Breeze stores files under public_html/wp-content/. Page cache is wp-content/cache/breeze/. Minified CSS/JS is wp-content/cache/breeze-minification/. Settings used at runtime are wp-content/breeze-config/. Varnish and Cloudflare are separate and are not inside these folders. Use Purge All Cache (and Varnish) instead of deleting files by hand.

Breeze's cached files get removed under a few different circumstances, not just one blanket rule:

Breeze deletes cached files so visitors do not see outdated HTML. It does this when you purge or save settings, when you update posts, comments, or WooCommerce stock, and when Purge Cache After is reached. A full purge empties the cache folders; a post update usually removes only that page and related URLs. New files are created on the next guest visit. On the Cloudways platform, also purge Varnish as that data is not stored in wp-content/cache/.

Breeze auto-purges cache when you save a public post, page, or custom post type. There is no Breeze setting to exclude a CPT from that. Never Cache URL(s) only stops caching, not purging. To skip auto-purge for a type such as book, use the breeze_collect_urls_for_cache_purge filter and return an empty list for that post type. Leave purge on for any type whose public pages must stay up to date.

No. RSS feeds should not be cached. Breeze already excludes /feed/ and ?feed= from page cache and minify. Leave that as it is. Add a custom feed URL to Never Cache URL(s) only if it does not contain /feed or feed=.

Breeze, Varnish, and Cloudflare each play a distinct role, and understanding how they hand off to one another is the key to avoiding stale content or confusing cache behavior. A few core principles to remember:

Keeping these distinctions in mind makes it much easier to diagnose caching issues quickly and configure Breeze correctly the first time.

That's it! We hope this article was helpful.