Caching and page speedPro
WP-Optimize MCP: a cache that has to be deployed, and a clean-up that cannot be undone
WP-Optimize MCP access in GoBuildWP Pro covers three quite different jobs. Turning the page cache on is a deployment, so the agent routes it through the plugin's own enable call that writes the drop-in. Minify settings have supported configuration recovery. Database clean-up permanently deletes selected rows: GoBuildWP cannot undo it; recovery requires a suitable backup and a separately tested restore procedure.
wp_optimize- Layer
- page
- Declared purge scopes
allurlpost- Shared keys
- 14
- Detected by
- constant WPO_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.
Abilities
The cache abilities on WP-Optimize
| Ability | What it does here | Undo and limits |
|---|---|---|
cache-get-settingscache-set-settings | Turning page_cache.enabled on or off calls WPO_Page_Cache::instance()->enable() or disable(), which write or remove advanced-cache.php and WP_CACHE; if the drop-in cannot be written, that failure is returned. The lifetime is split into the value and unit WP-Optimize stores. Minify keys go to wpo_minify_config under a minify. prefix. | Logged-in caching, merging CSS or JS and deferring JS are gated. Rollback-change restores wpo_cache_config and wpo_minify_config from the ledger. |
cache-list-actionscache-run-action | preload hands the job to WP-Optimize's own preloader, which batches and returns at once. optimize_database runs its clean-up of revisions, auto-drafts, spam and trashed comments, expired transients and table overhead, inline. | The clean-up is destructive, needs confirm, and deletes rows permanently. A queued preload has not finished when the call returns. |
cache-purgecache-warm | The whole cache purges through the WPO_Page_Cache singleton's purge(); URL and post purges use its static delete_cache_by_url() and delete_single_post_cache(). | Stateless. |
cache-set-nativecache-list-presetscache-apply-preset | Native writes reach the rest of both configurations by key. Conservative here is caching plus a lifetime; balanced adds WebP and minify; aggressive adds merging and JS defer. | Native writes and aggressive need confirm. |
cache-check-setupcache-measure-pagecache-verify-in-browsercache-begin-experimentcache-revert-experiment | Setup reports whether WP_CACHE is on with a drop-in present. Measurement, browser checks and experiment snapshots behave as for any page cache. | 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.
Data model
Two configurations and a file on disk
WP-Optimize keeps its page cache settings in wpo_cache_config, owned by WPO_Page_Cache, and its minifier in wpo_minify_config. The page-cache side is also mirrored to a PHP file that its advanced-cache.php drop-in reads on every request, so GoBuildWP writes it through the plugin's config object rather than update_option(); changing only the row would alter the settings screen and nothing a visitor receives.
Cached pages go in a wpo-cache folder inside wp-content/cache, per the plugin's listing. The lifetime is stored as page_cache_length_value and page_cache_length_unit; page_cache_length itself is recomputed on save.
Database clean-up is not configuration at all. It removes rows from WordPress tables, which is why it is modelled as an action and not a setting.
Page-cache keys go through WP-Optimize's own config object, and the on/off switch through its enable() and disable() methods, so the drop-in and the file it reads stay in step with the setting.
Shared key → WP-Optimize setting
page_cache.enabled → enable_page_cachingpage_cache.ttl → page_cache_lengthpage_cache.mobile_separate → enable_mobile_cachingpage_cache.cache_logged_in → enable_user_cachingpage_cache.exclusions → cache_exception_urlsimages.next_gen → use_webp_imagesimages.preload_lcp → lcp_preload_enablefonts.host_locally → minify.host_local_google_fontspreload.sitemap_driven → enable_sitemap_preloadcss.minify → minify.enable_csscss.combine → minify.enable_merging_of_cssjs.minify → minify.enable_jsjs.combine → minify.enable_merging_of_jsjs.defer → minify.enable_defer_js
Option rows
wpo_cache_configwpo_minify_config
Limits
Where WP-Optimize needs care
- Before optimize_database, review the deletion categories and verify a suitable database backup. GoBuildWP cannot restore deleted rows; recovery is a separate backup restore.
- fonts.host_locally lands on the minifier's host_local_google_fonts, off until someone saves it. It works through the minifier's CSS processing, so it changes nothing on pages the minifier is not handling. Before GoBuildWP Pro 1.12.4 the key pointed at host_gravatars_locally, the page cache's Gravatar setting, so if an agent set it earlier, check that switch in WP-Optimize's cache screen.
- The smallest lifetime unit is an hour, so a sub-hour value is rounded up rather than down to zero, which would switch expiry off.
- A rollback or experiment revert writes the option rows directly; save the cache screen once afterwards so the file the drop-in reads matches them.
- Enabling the cache fails, and says so, when wp-content is not writable.
Worked example
Switch on the page cache and fill it
Expected outcome to verify on the installed stack; this sequence has not been recorded as a runtime test.
The reply records cache deployment and the request to WP-Optimize's preloader. Inspect its progress and test eligible URLs before claiming the cache is populated. If enable() cannot write the drop-in, the setting is not reported as on, and check-setup still shows WP_CACHE off.
fonts.host_locally maps to the minifier's host_local_google_fonts and acts only where the minifier processes CSS; confirm font requests no longer go to Google in the browser. Keep irreversible cleanup categories backed up. A present drop-in and WP_CACHE are separate conditions to inspect.
WP-Optimize is installed but the page cache is off. Turn it on with a day-long lifetime and preload the site.
wppilot/cache-check-setupReadShows WP-Optimize active, WP_CACHE off and no drop-in, so nothing is caching pages yet.
wppilot/cache-set-settingsWritepage_cache.enabled and a lifetime of one day; enable() writes the drop-in and the lifetime is stored as value and unit.
wppilot/cache-run-actionConfirm firstpreload queues WP-Optimize's preloader and returns straight away.
wppilot/cache-measure-pageReadTaken later, after the queue has run, to see the homepage served from cache.
A suggested sequence from the ability reference, not a recorded run.
A clean-up to fence off, lists written whole, two write paths
Fencing off WP-Optimize's database clean-up on a live site
WP-Optimize MCP access includes one call that deletes data: the optimize_database action, run through cache-run-action. It is marked destructive, so the action needs confirm=true and the safety layer asks for confirmation on top. Read Only blocks it outright. On Production Safe it runs once someone approves it, which is exactly when a hurried yes does the damage.
If the clean-up should never be one approval away on production, an administrator can add a rule in the Abilities Hub that disables cache-run-action or raises its minimum profile to Developer Full Access. The rule covers the whole ability, so the preload action is fenced off with it; preloading can still happen through WP-Optimize's sitemap preload, which cache-set-settings reaches as preload.sitemap_driven. The security page explains how profiles and rules combine.
LCP preload, exclusions and other WP-Optimize keys by name
Some mapped keys reach WP-Optimize features that are worth knowing by their stored names. images.preload_lcp lands on lcp_preload_enable, page_cache.exclusions on cache_exception_urls, preload.sitemap_driven on enable_sitemap_preload, and page_cache.cache_logged_in on enable_user_caching, which is gated. images.next_gen lands on use_webp_images, so the balanced preset switches WebP use on here as well as minify.
Exclusions are a list, and the list is written whole. Asking the agent to add one URL means reading cache_exception_urls first and sending the existing entries plus the new one; sending only the new URL would replace the rest. The same applies to a native write on any list held in wpo_cache_config.
Why minify changes take a different path from page-cache changes
cache-set-native reports write_path mixed on WP-Optimize. Page-cache keys go through the plugin's own cache config object, which keeps the file its drop-in reads in step. Keys with the minify. prefix are written straight to wpo_minify_config, so anything WP-Optimize does only when its minify screen is saved has not run. The purge that follows a write is the page cache's purge(); GoBuildWP does not call a separate minify clear, so if pages still reference old minified files, clear them from WP-Optimize's minify screen and purge the page cache again.
WP-Optimize requests and what the agent can answer
The last prompt below is one the cache abilities cannot answer, and the agent should say so rather than guess.
- "Is WP-Optimize's page cache actually deployed? Check WP_CACHE and the drop-in, read only."
- "Add /members/ to the cache exclusions without dropping the existing ones."
- "Turn on LCP preload, purge, and give me the browser checks for the homepage hero."
- "How many revisions would the clean-up remove?" The action returns whether its entry point ran, not a count of what it deleted, so check WP-Optimize's own database screen before approving it.
Questions
WP-Optimize questions
Can the agent undo a WP-Optimize database clean-up?
No. The action deletes rows permanently, which is why it requires your confirmation. Only settings changes have an undo.
Why did a 30-minute cache lifetime become one hour?
WP-Optimize's smallest unit is an hour. GoBuildWP rounds up so the cache still expires, rather than rounding to zero and disabling expiry.
Is the preload finished when the agent reports it ran?
No. It is queued through WP-Optimize's preloader, which works in batches. Measure again later rather than straight away.
Other plugins
WP-Optimize with another page cache
- WP-Optimize says it cannot run alongside another page cache because both need advanced-cache.php; its advice is to turn off its caching and keep its other features.
- WP Rocket and WP Fastest Cache both list WP-Optimize among plugins not to combine with.
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-Optimize is a separate product; no partnership or endorsement is implied.