Caching and page speedPro
Breeze MCP: tuning Cloudways' cache plugin from an AI agent
Breeze MCP access through GoBuildWP Pro gives an agent the Breeze switches whose meaning is plain from their names: caching, lifetime, mobile cache, browser cache, minify, grouping, lazy loading, URL exclusions and link preloading. Purging is all-or-nothing, since Breeze offers a clear-all hook and, according to its author, no per-post purge. On Cloudways servers Varnish often sits in front, which GoBuildWP reports but does not purge.
breeze- Layer
- page
- Declared purge scopes
all- Shared keys
- 12
- Detected by
- constant BREEZE_VERSION
Installed class, method or listener checks and per-layer results determine whether a purge ran. Neither a declaration nor a returned ran flag proves public freshness.
- Edition
- Pro
- Abilities
- 16
- Requires
- WordPress 6.9+, PHP 8.0+
Before changing cache settings, inspect captured drivers and not_captured. After reverting, inspect restored, deleted, not_restored, verified and purged_layers. Use a separate cache-purge result when you need details for each layer. Storage verification checks captured values; it does not establish functional recovery or public freshness. Revert may overwrite later settings, and vendor configuration regeneration or a re-save can still be required.
Check each measurement run’s fetched_via before treating it as public-path evidence. cache-verify-in-browser supplies checks and does not operate a browser. Automatic purge coalesces targets within the request and runs on shutdown; it is not necessarily one immediate flush per call. Verify generated files, object/page/edge caches and actual visitor behavior separately.
Other plugins
Breeze is meant to be the only cache
- Breeze's listing says not to run two WordPress cache plugins together and to use Breeze as the only one.
- When we read their documentation on 29 September 2026, WP Rocket listed Breeze as incompatible unless the site uses Cloudways' Cloudflare Enterprise setup, and WP Fastest Cache named Breeze among plugins to disable. These are the vendors' statements, not tests GoBuildWP ran; check their current notes before relying on them.
- FlyingPress says it turns off conflicting optimisations in Breeze automatically when both are active; that is the vendor's description, not something GoBuildWP has verified.
- Breeze's own listing describes it as tested with Cloudways servers that come with Varnish (a vendor statement); check-setup lists such an edge from the response headers, and cache-purge does not reach it.
Data model
Settings grouped into several rows
Breeze splits its configuration across breeze_basic_settings, which holds the cache and minifier switches, breeze_advanced_settings, which holds lazy loading, exclusions, grouping and link preloading, and further rows for files, CDN integration and preload. GoBuildWP names each setting as row:key, for example breeze_basic_settings:breeze-ttl or breeze_advanced_settings:breeze-exclude-urls, and stores checkboxes as the strings 1 and 0 as Breeze does.
Breeze writes those rows only once its settings screen has been saved. On a fresh install they do not exist, so every mapped key declares a default and reads as that value instead of as missing.
Only keys whose meaning is unambiguous from the name are mapped. A Breeze key that meant something adjacent to its name would otherwise be written confidently and wrongly.
Changes are grouped by row and merged into breeze_basic_settings or breeze_advanced_settings, leaving every key GoBuildWP did not name exactly as it was.
Shared key → Breeze setting
page_cache.enabled → breeze_basic_settings:breeze-activepage_cache.ttl → breeze_basic_settings:breeze-ttlpage_cache.mobile_separate → breeze_basic_settings:breeze-mobile-cachebrowser_cache.enabled → breeze_basic_settings:breeze-browser-cachecss.minify → breeze_basic_settings:breeze-minify-cssjs.minify → breeze_basic_settings:breeze-minify-jscss.combine → breeze_advanced_settings:breeze-group-cssjs.combine → breeze_advanced_settings:breeze-group-jsimages.lazyload → breeze_advanced_settings:breeze-lazy-loadimages.lazyload_iframes → breeze_advanced_settings:breeze-lazy-load-iframespage_cache.exclusions → breeze_advanced_settings:breeze-exclude-urlspreload.links_on_hover → breeze_advanced_settings:breeze-preload-links
Option rows
breeze_basic_settingsbreeze_advanced_settingsbreeze_file_settingsbreeze_cdn_integrationbreeze_preload_settings
Worked example
Keep the checkout out of the cache
Expected outcome to verify on the installed stack; this sequence has not been recorded as a runtime test.
An exclusion request requiring synthetic checkout verification at each delivery layer. A HIT alone does not identify Varnish or establish safe cart/session bypass.
Specify the exact requested URL purge scope and preserve exclusion arrays. GoBuildWP has no direct Varnish call here; inspect whether configured plugin hooks cascade to Varnish.
Make sure Breeze never caches /checkout/ and show me it is working.
wppilot/cache-get-settingsReadReturns page_cache.exclusions from breeze-exclude-urls, possibly the default if the settings screen was never saved.
wppilot/cache-set-settingsWriteAdds the checkout path to the exclusion list in breeze_advanced_settings; the write is recorded with its before-image.
wppilot/cache-purgeWriteBreeze has only a clear-all hook, so the whole cache is emptied and the result says the scope widened.
wppilot/cache-measure-pageReadRequests /checkout/ twice; a hit on checkout would mean some layer is caching it and needs an exclusion. A miss on two server-side requests is consistent with the exclusion, not proof of it for every visitor.
A suggested sequence from the ability reference, not a recorded run.
Abilities
The cache abilities on Breeze
| Ability | What it does here | Undo and limits |
|---|---|---|
cache-purgecache-warm | Fires breeze_clear_all_cache, only when has_action confirms Breeze listens. URL and post requests widen to that and say so. | Whether Breeze's own clear also empties Varnish is Breeze's behaviour, which GoBuildWP does not verify. Purges cannot be undone. |
cache-get-settingscache-set-settings | Mapped: breeze-active, breeze-ttl, breeze-mobile-cache, breeze-browser-cache, both minify switches, group CSS and group JS, lazy load for images and iframes, exclude URLs and preload links. | Grouping CSS or JS needs confirm. Rollback-change restores the rows from the ledger. |
cache-set-native | Reaches keys in the files, CDN and preload rows that have no shared name. | Confirm required. |
cache-list-presetscache-apply-preset | Conservative turns on caching, a lifetime, browser caching and both lazy-load switches; balanced adds minify; aggressive adds grouping. | Aggressive needs confirm. |
cache-check-setupcache-measure-pagecache-verify-in-browsercache-list-actionscache-run-actioncache-begin-experimentcache-revert-experiment | Detection by BREEZE_VERSION with edge layers listed, delivery measurement, browser checks, and experiment snapshots of the Breeze rows. No Breeze actions are declared. | Revert needs confirm. |
Reference: /docs/reference/cache
Shared cache module; do not add this count across drivers. Edition and effect labels describe the source catalogue. The installed schema, dependency versions, licence, WordPress capability, safety profile and per-ability policy determine availability; labels alone do not prove confirmation or recovery.
Limits
What the Breeze driver cannot do
- No purge for a single URL or post; every purge clears the whole Breeze cache.
- Varnish and Cloudflare in front of a Cloudways site are not purged by cache-purge.
- Breeze's CDN, Cloudflare and Heartbeat features have no shared keys; use native keys or its screen.
Breeze in a real migration
Moving a site onto Breeze from another cache plugin
Sites usually meet Breeze when they move to Cloudways, often still carrying the cache plugin from the old host. Breeze asks to be the only cache, so the job is a handover, and the shared vocabulary makes it less error-prone than reading two settings screens side by side. cache-check-setup lists every active layer, which on a mid-migration site will show two page caches. cache-get-settings on the outgoing plugin returns its configuration in the same canonical keys Breeze uses, so its URL exclusions, lifetime and lazy-load choices can be carried across where both plugins map the key.
Start an experiment before touching either plugin, so one id can restore both if the handover goes wrong. Write the carried-over values into Breeze with cache-set-settings, leaving grouping off for now, then switch the old plugin off with deactivate-plugin. Plugins that install a drop-in or rewrite rules may leave pieces behind; check-setup's report of WP_CACHE and the advanced-cache.php drop-in shows whether the outgoing plugin cleaned up after itself. Only once Breeze is the single page layer is it worth measuring anything.
- Exclusions for cart, checkout and account pages are the values that must survive the move; read them back from Breeze before switching the old plugin off.
- Keys the old plugin had and Breeze does not map, such as delay-JS lists on some plugins, are reported as unsupported rather than silently lost; decide what replaces them.
- Deactivating a cache plugin is a plugin action, not a cache setting, so experiment revert will not reactivate it.
Telling Breeze hits from Varnish hits on Cloudways
cache-measure-page reports whether a response came back as a hit or a miss from the cache headers it sees, and on a Cloudways server more than one layer can answer. A hit after a Breeze change may come from Varnish in front of WordPress, which says nothing about whether Breeze itself is caching that URL. Read the edge_layers that check-setup found, look at which header carried the result, and check the measurement's fetched_via before treating it as public evidence. When the server fetches its own URL by an internal route, the result can skip layers a visitor would pass through.
The same caution applies after a purge. GoBuildWP calls Breeze's clear-all hook and reports that it ran; whether Breeze passes the clear on to Varnish is Breeze's behaviour and is not verified from here. If a change does not show for a logged-out visitor, purge Varnish from the Cloudways panel before assuming the Breeze setting failed.
Mobile cache and lifetime choices
Separate mobile caching only matters when the theme or a plugin sends different HTML to phones. A responsive theme that serves one document to every device gains nothing from it and doubles what has to be warmed after a purge. Ask the agent to fetch a page as both before turning it on. The lifetime is a trade between how long a page can be stale and how often an uncached visitor pays for a full build; on a site that publishes daily, a long lifetime mostly matters because every purge resets it anyway.
Questions
Breeze questions
Why does purging one page from the agent clear all of Breeze?
Breeze's author has said there is no per-post purge, and GoBuildWP calls the clear-all hook rather than leave a stale page.
The agent says a setting is at its default but I never set it. Is that right?
Yes. Breeze creates its rows only when its settings screen is saved, so until then GoBuildWP reports the default Breeze would use.
Does the agent work on Breeze outside Cloudways?
Breeze is a general WordPress plugin and the driver does not depend on the host. Varnish integration is the part tied to Cloudways servers.
Where these facts come from
GoBuildWP behaviour is taken from the plugin source and the ability reference; third-party details from the vendor documentation below, checked by the GoBuildWP team.
Breeze is a separate product; no partnership or endorsement is implied.