Caching and page speedPro
WP Rocket MCP: settings that reach the drop-in, and a way back
WP Rocket MCP support in GoBuildWP Pro treats a settings write as unfinished until two follow-up steps happen: the config file that WP Rocket's advanced-cache drop-in reads is regenerated, and the pages already stored are cleared. An agent can then tune file optimisation, lazy loading, preload and delayed JavaScript, measure the result, and restore the previous wp_rocket_settings row when a script stops working.
wp_rocket- Layer
- page
- Declared purge scopes
allurlpost- Shared keys
- 24
- Detected by
- constant WP_ROCKET_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.
Data model
One settings row, one generated file, many cache folders
WP Rocket holds every setting in a single option, wp_rocket_settings, and documents get_rocket_option() and update_rocket_option() as the way to change it from code. The shared vocabulary lands on its keys: js.delay on delay_js, page_cache.ttl on the purge_cron_interval and purge_cron_unit pair that together make the cache lifespan, css.unused_css_removal on remove_unused_css, page_cache.cache_logged_in on cache_logged_user, preload.sitemap_driven on sitemap_preload, and the two database clean-up switches on database_revisions and database_transients.
What visitors receive comes from disk. WP Rocket's documentation puts cached pages under wp-content/cache/wp-rocket/ per domain, with sibling folders for minified files, critical CSS and used CSS, and some features keep their own database tables such as wp_wpr_above_the_fold. None of that is configuration; it is output rebuilt from the row.
There is no switch that turns the page cache off. It runs whenever the plugin is active, and deactivation is the only off state, which is not a settings write, so page_cache.enabled is absent from the map and every preset skips it.
Each key goes through update_rocket_option(); then rocket_generate_config_file() rewrites the file the drop-in reads and rocket_clean_domain() discards pages built under the old values. Skip either and the row says one thing while visitors keep getting the other.
Shared key → WP Rocket setting
page_cache.ttl → purge_cron_interval+purge_cron_unitpage_cache.mobile_separate → do_caching_mobile_filespage_cache.cache_logged_in → cache_logged_userpage_cache.exclusions → cache_reject_uricss.minify → minify_csscss.combine → minify_concatenate_csscss.critical → async_csscss.unused_css_removal → remove_unused_cssjs.minify → minify_jsjs.combine → minify_concatenate_jsjs.defer → defer_all_jsjs.delay → delay_jsjs.delay_exclusions → delay_js_exclusionsimages.lazyload → lazyloadimages.lazyload_iframes → lazyload_iframesimages.dimensions → image_dimensionsimages.next_gen → cache_webpcdn.enabled → cdncdn.hosts → cdn_cnamespreload.enabled → manual_preloadpreload.sitemap_driven → sitemap_preloadpreload.links_on_hover → preload_linksdatabase.revisions_cleanup → database_revisionsdatabase.transient_cleanup → database_transients
Option rows
wp_rocket_settings
Limits
Before an agent touches WP Rocket
- Delay JavaScript is confirmation-gated and missing from every preset, so it only changes when someone asks for it by name.
- A rollback or experiment revert writes wp_rocket_settings back directly without regenerating the config file; save WP Rocket's settings screen once afterwards so the drop-in matches.
- The cache folders and WP Rocket's own tables are output, not settings, and are never snapshotted.
- WP Rocket's documentation says preload will not work when the host runs its own page caching, and it needs a working WP-Cron or a server cron.
Abilities
How each cache ability lands on WP Rocket
| Ability | What it does here | Undo and limits |
|---|---|---|
cache-get-settingscache-set-settings | Reads and writes the mapped keys inside wp_rocket_settings, including delay_js and its exclusion list, async CSS for css.critical, CDN on and CNAME hosts, and link preloading on hover. | The gated set is wide on this plugin: logged-in caching, both combine switches, async CSS, unused CSS removal, defer, delay and both CDN keys. The whole row is the before-image, so rollback-change puts all of it back. |
cache-set-native | Anything else in the row, addressed by the key name include_native shows, still passes through the same regenerate-and-clear sequence. | Always asks for confirm, and the snapshot is again the full row. |
cache-list-presetscache-apply-preset | Conservative here means a one-day cache lifespan, stored as 1 in purge_cron_interval with DAY_IN_SECONDS in purge_cron_unit, plus lazy loading, iframe lazy loading and image dimensions. Aggressive adds combining, async CSS and defer. Delay JavaScript belongs to no preset. | Aggressive refuses without confirm; one ledger entry covers the whole preset. |
cache-purgecache-warmcache-measure-page | Purge calls rocket_clean_domain(), rocket_clean_files() with a URL list, or rocket_clean_post(). Warming then requests the pages again so the measurement times cache delivery rather than a page build. | Nothing to undo. RocketCDN, Cloudflare or another edge is not purged by this call. |
cache-list-actionscache-run-action | GoBuildWP declares no WP Rocket actions: preload is a setting here, and database clean-up is two settings keys rather than a one-off job. | run-action has nothing to run on this plugin and says so. |
cache-check-setupcache-verify-in-browsercache-begin-experimentcache-revert-experiment | Setup detects WP_ROCKET_VERSION and lists any optimiser stacked beside it. The browser checks target console errors and an undefined jQuery, what delayed scripts break first. An experiment stores the row alongside every other layer. | Revert is gated by confirm and restores the row directly. |
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.
Worked example
Delay JavaScript without losing the cookie banner
Expected outcome to verify on the installed stack; this sequence has not been recorded as a runtime test.
Delayed scripts on a warmed page, measured before and after. If the banner dies, rollback-change on that entry restores the previous row; adding the banner script to delay_js_exclusions is the gentler second attempt.
Review the site-wide setting scope and preserve supported exclusion arrays. page_cache.ttl is read and written as WP Rocket's interval and unit; a value that is not whole hours reports applied: false. After revert, re-save natively when required, then check expected content, cookie controls and menu interactions.
Review WP Rocket's site-wide delay JavaScript setting and any supported exclusions before changing it. Test the blog, cookie banner and menu; revert if they stop working.
wppilot/cache-get-settingsReadShows delay_js off and the current delay_js_exclusions list, plus which keys are marked risky.
wppilot/cache-measure-pageReadRecords head scripts and time to first byte on a blog post before anything changes.
wppilot/cache-set-settingsWriteWith the owner's approval, js.delay goes in with confirm; the row is updated, the config file regenerated and the domain cleared.
wppilot/cache-warmWriteRequests the blog post so the cache can hold it again before the next reading.
wppilot/cache-verify-in-browserReadReturns the checks to run: console clean, jQuery defined, banner and menu respond to a click.
A suggested sequence from the ability reference, not a recorded run.
Domain-wide clears, the lifespan key and a read-only audit
Every WP Rocket settings write empties the whole cache
WP Rocket MCP tuning has a cost the settings screen hides. GoBuildWP's WP Rocket writer ends every write by regenerating the config file and calling rocket_clean_domain(), so each settings change, canonical or native, clears every cached page on the domain. The purge flag on cache-set-native does not prevent this, because the clear happens inside the write itself, before the separate purge step.
Tuning one key at a time is still the right method, but on a large site each step sends visitors to uncached pages until something rebuilds them. cache-warm requests at most ten URLs per call, giving WP Rocket the chance to cache them again, enough for the pages you are measuring and no more. For the rest, rely on WP Rocket's own preload, which cache-set-settings reaches as preload.enabled on manual_preload and preload.sitemap_driven on sitemap_preload, and schedule tuning for quiet hours.
How page_cache.ttl maps onto WP Rocket's lifespan
WP Rocket stores its cache lifespan as two settings: purge_cron_interval, a count, and purge_cron_unit, which names hours or days. From GoBuildWP Pro 1.12.4 the shared key page_cache.ttl reads and writes the pair together. cache-get-settings reports the lifespan in seconds, calculated the way WP Rocket calculates it, so the plugin's default of 10 hours reads as 36000. A whole number of days is stored in days; anything else is stored in hours, rounded up so a short lifespan never becomes zero, and the write reports applied: false with the lifespan actually in force. Sending 0 turns expiry off.
Every preset sets a one-day lifespan, which is now stored as 1 day. Older Pro versions wrote the seconds into the count alone, so a preset applied before 1.12.4 on a site using hours could have left a lifespan of 86400 hours, about ten years. After updating, cache-get-settings shows such a value as far more than 86400 seconds; set page_cache.ttl again, or correct the lifespan in WP Rocket's cache settings. cache-set-native still treats purge_cron_interval as the bare count in whatever unit purge_cron_unit already holds.
A WP Rocket audit that runs entirely under Read Only
An owner who wants to see what WP Rocket is doing before granting any write can keep the connection on the Read Only safety profile. cache-check-setup, cache-get-settings with include_native, cache-list-presets, cache-measure-page and cache-verify-in-browser all run there for a user with manage_options, and together they show the whole wp_rocket_settings row, which keys are gated, what each preset would change, and whether pages come back cached. The x-wp-rocket header is reported verbatim when the server sends it; when it does not, timing and warm results carry the evidence.
Moving to Production Safe adds writes. Ungated keys such as lazyload, image_dimensions or minify_css apply directly; delay_js, remove_unused_css, async_css, defer_all_js, both concatenate switches, cache_logged_user and the two CDN keys are refused until confirm=true. The security model shows how profiles and confirmation fit together.
- "Read wp_rocket_settings and list which gated keys are on. Don't change anything."
- "Turn on image dimensions, warm the five pages I list and compare time to first byte."
- "What would the balanced preset change on this site? Show would_change only."
Questions
WP Rocket questions
Does the agent's WP Rocket change take effect without pressing Save Changes?
Yes. After writing the row GoBuildWP regenerates the config file and clears the domain, the two steps a programmatic write would otherwise miss.
Why doesn't the agent offer to turn WP Rocket's cache off?
WP Rocket has no such setting; the cache runs while the plugin is active. Deactivating the plugin is a plugin operation, not a cache setting, and the cache abilities do not do it.
How does the agent set WP Rocket's cache lifespan?
Through page_cache.ttl in seconds. From GoBuildWP Pro 1.12.4 it is stored as the count and unit WP Rocket's settings screen offers: whole days in days, anything else in hours rounded up, with applied: false when rounding changed the value. 0 switches expiry off.
Is there WP-CLI support the agent could use instead?
WP Rocket documents PHP functions such as rocket_clean_domain() and rocket_clean_post() rather than its own WP-CLI commands, and those functions are what the purge calls.
WP Rocket documents its own MCP integration. GoBuildWP's cache module exposes only the settings and purge scopes declared below. Neither a settings write nor a purge proves a Core Web Vitals improvement. WP Rocket MCP documentation
Other plugins
What WP Rocket shares a site with
- WP Rocket's compatibility list names LiteSpeed Cache, WP Fastest Cache, WP-Optimize and W3 Total Cache as not compatible, and Breeze unless it is Cloudways' Cloudflare Enterprise setup.
- Autoptimize conflicts only when its minify or aggregation runs alongside WP Rocket's; with those off in one plugin, cache-purge clears both layers together.
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.
- WP Rocket features
- Manually clear the WP Rocket cache
- Clear WP Rocket cache via cron job
- Optimisation plugins not compatible with WP Rocket
WP Rocket is a separate product; no partnership or endorsement is implied.