Caching and page speedPro
SpeedyCache MCP: preload, expired-page clean-up and the settings GoBuildWP has verified
SpeedyCache MCP support in GoBuildWP Pro leans on actions more than settings. An agent can run SpeedyCache's own preloader, remove cached pages past their lifetime, and purge everything, a list of URLs or one post through its Delete class. The settings it maps are only the ones checked against the plugin's source: caching on or off, logged-in caching, speculative link loading, the object cache and the CDN.
speedycache- Layer
- page
- Declared purge scopes
allurlpost- Shared keys
- 6
- Detected by
- constant SPEEDYCACHE_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.
Worked example
Rebuild the cache after a redesign
Expected outcome to verify on the installed stack; this sequence has not been recorded as a runtime test.
Preload was requested. Inspect the vendor queue or status before claiming completion, then verify the homepage response and expected content. A checked homepage does not prove a site-wide rebuild.
preload.links_on_hover maps to speculation_loading and does not establish a hover trigger. Treat it as semantically unverified for hover use. Inspect installed Pro-only availability and vendor preload queue completion before accepting the workflow.
We just launched the new theme. Clear SpeedyCache, build the cache back up for the whole site, and tell me when the homepage is served from it.
wppilot/cache-list-actionsReadShows preload and clean_expired, both non-destructive, both blocking, and whether each entry point resolves here.
wppilot/cache-purgeWriteScope all calls SpeedyCache\Delete::all_cache() and names it in the per-layer result.
wppilot/cache-run-actionConfirm firstpreload runs SpeedyCache\Preload::cache() inline, which can take a while on a large site.
wppilot/cache-measure-pageReadChecks the homepage's cache status and time to first byte once the preload has returned.
A suggested sequence from the ability reference, not a recorded run.
Data model
Small rows, split by concern
SpeedyCache spreads its configuration over several small option rows rather than one blob: speedycache_options for the cache itself, speedycache_cdn, speedycache_object_cache and speedycache_img. GoBuildWP addresses each setting as row:key, so the page cache switch is speedycache_options:status and the CDN host is speedycache_cdn:cdn_url.
Only those rows have been confirmed against SpeedyCache's source. Its minification and image settings live in rows whose key names have not been verified, so they are not mapped; they remain in the native read and the plugin's own screens.
SpeedyCache's listing splits features between free and Pro, with WebP, critical and unused CSS, the Redis object cache, delay JS and mobile cache in Pro. A write to a Pro-only switch on the free edition is something to check on the page, not assume.
Writes are grouped by row and merged into speedycache_options, speedycache_cdn or speedycache_object_cache, so keys GoBuildWP does not know inside those rows are kept.
Shared key → SpeedyCache setting
page_cache.enabled → speedycache_options:statuspage_cache.cache_logged_in → speedycache_options:logged_in_userpreload.links_on_hover → speedycache_options:speculation_loading- speculation_loading; hover semantics unverifiedobject_cache.enabled → speedycache_object_cache:persistentcdn.enabled → speedycache_cdn:enabledcdn.hosts → speedycache_cdn:cdn_url
Option rows
speedycache_optionsspeedycache_cdnspeedycache_object_cachespeedycache_img
Limits
Where SpeedyCache coverage stops
- No shared key for minify, combine, lazy load or images; those stay in native rows or the plugin screen.
- All three presets reduce to switching the page cache on here, because nothing else they contain is mapped.
- Logged-in caching, the CDN switch and CDN hosts are gated behind confirm.
- SpeedyCache's own admin purge is a nonce-checked form request, so GoBuildWP uses the Delete class instead.
Abilities
Each cache ability on SpeedyCache
| Ability | What it does here | Undo and limits |
|---|---|---|
cache-list-actionscache-run-action | preload walks the site with SpeedyCache\Preload::cache(); clean_expired removes cache files past their lifetime with Delete::expired_cache(). The second is disk housekeeping, not a speed change. | Neither is destructive and neither can be undone. |
cache-purgecache-warm | Delete::all_cache(), Delete::url() with a URL list, or Delete::cache() for a post; warming requests up to ten URLs afterwards. | No state to restore. |
cache-get-settingscache-set-settingscache-set-native | Shared keys cover the status switch, logged_in_user, speculation_loading for link preloading, the persistent object cache and both CDN fields; native writes reach the rest of the four rows. | Gated keys and every native write need confirm. Rollback-change restores the rows from the ledger. |
cache-list-presetscache-apply-preset | Each preset sets only the page cache switch on this plugin, and the preview lists the rest as unsupported. | No preset needs confirm here. |
cache-check-setupcache-measure-pagecache-verify-in-browsercache-begin-experimentcache-revert-experiment | Detection by SPEEDYCACHE_VERSION, delivery measurement, browser checks, and a snapshot of the rows for revert. | 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.
Questions
SpeedyCache questions
SpeedyCache says it has its own abilities for AI clients. Why use GoBuildWP's?
SpeedyCache's listing says it exposes cache management through the WordPress Abilities API; GoBuildWP has not verified those abilities' names and does not call them. What GoBuildWP adds is purging every stacked layer at once, ledger undo for settings, and measurement.
Does clean_expired make the site faster?
Not by itself. It deletes cache files past their lifetime to save disk space; fresh pages are unaffected.
Can the agent use SpeedyCache's WP-CLI commands?
It does not. SpeedyCache documents wp speedycache clear cache for you to run; the agent calls the PHP classes directly.
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.
SpeedyCache is a separate product; no partnership or endorsement is implied.