Pro module16 abilities

Cache and page speed ability reference

Reference for the GoBuildWP Pro 1.12.4 source. Installed schemas and policy remain authoritative.

This Cache and page speed ability reference lists every call GoBuildWP Pro registers for cache purge, warm-up, presets and speed experiments, with the exact slug an agent sends and what the plugin's own contract says it does. Of the 16, 7 read, 6 write and 3 are marked destructive in the source.

By GoBuildWPContent updated 13 October 2026How we check claims

Read-only, write and destructive groups describe the source annotations. They do not establish a minimum safety profile, human approval or undo support. Those controls are separate: check the installed ability, the connected user and the active site policy before calling it. A read can still return sensitive data. These pages are not evidence that every operation passed an end-to-end runtime test.

What Cache and page speed needs before these load

These 16 abilities come with GoBuildWP Pro 1.12.4. Pro registration requires the Freemius SDK to permit premium code and any companion dependency the module checks to be available. The module declares no version floor of its own; dependency and permission checks still apply. wppilot/integration-health and the module's setup call describe the installed availability.

Cache and page speed editions: free, pro
Agent skills shipped: cache-optimization, pagespeed-fix

Cache and page speed reads

Ability	What it does
`wppilot/cache-check-setup`Check Cache Setup	Reports every caching layer in front of this site: the page-cache and asset-optimisation plugins that are active (with version, driver key, whether their settings can be read and written, and whether they are mapped onto the shared canonical vocabulary or reachable only by their own key names), whether a persistent object cache is in use, whether WP_CACHE is on with an advanced-cache.php drop-in, and which CDN, WAF or host edge layers answered the site's own request headers. Also lists the purge scopes each layer actually supports on this install, and whether automatic purge-after-write is enabled. A site normally runs more than one layer at once — an asset optimiser in front of a page cache in front of a CDN — so this returns a LIST, not a single winner. Call this first before any other cache ability.
`wppilot/cache-get-settings`Get Cache Settings	Reads one cache layer's configuration in a canonical vocabulary shared across every supported plugin, so the same key means the same thing whether the site runs LiteSpeed, WP Rocket or W3 Total Cache. Groups: page_cache, browser_cache, object_cache, css, js, images, fonts, cdn, preload, database. `unsupported` lists the canonical keys this plugin has no equivalent for — treat those as absent features, not as settings that failed to read. `risky_keys` marks the ones cache-set-settings will refuse without confirm=true. Set include_native=true to also get the native settings the installed driver can enumerate, beyond the canonical model, with credentials withheld — with `native_complete` saying whether it fit inside the size cap. Available keys vary by installed plugin and version. Use cache-set-native only for keys that the driver can read back and permits writing; a native read is not a promise that every displayed value is writable. Omit `driver` when the site has exactly one page cache; when several are stacked the call names them and asks you to choose.
`wppilot/cache-list-actions`List Cache Actions	Lists the cache operations available on this site that are actions rather than settings — running a crawler so pages are cached before a visitor arrives, preloading the page cache, cleaning the database that every uncached page load has to query. Each entry says whether it is destructive, whether it blocks while it works, and whether its entry point actually resolves on this install; an action listed as unavailable is one the plugin does not expose in a way that can be called from here. Settings are cache-get-settings and cache-set-settings; this is the other half.
`wppilot/cache-list-presets`List Cache Presets	Lists the named cache configurations — conservative, balanced, aggressive — with, for each one, the canonical keys it sets, which of those the active plugin actually supports, which are confirmation-gated, and which would change from the site's current values. Read this before cache-apply-preset: the "would change" list is the honest preview of what applying it does here, on this site, with this plugin, rather than what the preset says in the abstract.
`wppilot/cache-measure-page`Measure Page Delivery	Fetches one URL of this site from the server and reports what the response itself proves: time to first byte across repeated requests, whether the cache reported a HIT or a MISS (x-litespeed-cache, x-cache, cf-cache-status and friends), HTML byte weight and whether it was compressed, how many render-blocking stylesheets and head scripts the document loads, how many images ship without width/height or a loading attribute, and whether any font is preloaded. This is server-side delivery, NOT a Lighthouse score and NOT Core Web Vitals — it cannot see LCP, CLS or INP, because those only exist once a browser renders. Measure those in a browser and use this for the half a browser cannot tell you: whether the cache actually engaged, and what the document is asking the browser to do before it can paint. If the server cannot reach its own public URL — normal on containerised or proxied sites, where the port in the site URL belongs to the host — it retries once on the local interface with the site's Host header and reports that in `runs[].fetched_via` rather than hiding it.
`wppilot/cache-verify-in-browser`Verify In Browser	Names what an optimisation is most likely to have broken on one URL, and hands back the exact browser checks that would prove it either way. This ability does NOT run a browser: WordPress has no browser to run, and a headless one bolted into PHP would be a second thing to trust rather than the thing the visitor actually sees. It reads the delivered HTML, marks the elements a cache plugin most often damages — an above-the-fold image that got lazy-loaded, an image served over http on an https page, an image with no intrinsic size — and returns `browser_checks`, each one a snippet to run in a real browser you have open, with the result that counts as a pass. Run the checks, then fix what fails, one at a time. The point is that `cache-set-settings` reporting `applied: true` for every key proves only that the option row was written; it cannot see that the header logo is now a transparent placeholder, and neither can any server-side audit. A browser can. It also returns `pagespeed`: the PageSpeed Insights report URLs for both form factors and the snippet that reads the scores and failing audits out of the page, so the score comes from the same browser and needs no API key — the keyless PSI API quota is shared globally and often answers 429. Where the site is not reachable from the public internet it says so instead of sending the agent to a report that cannot run. It also returns `blocked_by_environment`: what is wrong here that no WordPress setting can fix, and the steps for whoever owns that layer. That list exists because the expensive failure is a silent one — a setting written, read back correctly, reported as applied, and doing nothing on the wire because the thing that would carry it out lives outside WordPress. Without it an agent tunes the same key repeatedly and reports progress no visitor experiences. Use `cache-measure-page` for the delivery numbers this cannot see, and this for the render damage and the public score those numbers cannot see.
`wppilot/pagespeed-fix-plan`Plan a PageSpeed Fix	Reads a page's PageSpeed opportunities (wppilot/pagespeed-check from GoBuildWP Free, or a result you pass as baseline) and this site's cache layer (cache-get-settings), and names the ONE cache setting that addresses the largest opportunity it can: for example js.defer for render-blocking resources, images.lazyload for offscreen images, images.next_gen for image delivery, page_cache.enabled for a slow server response. Says which opportunities no cache setting can fix, which keys this plugin lacks and which are already on. Changes nothing. Run wppilot/pagespeed-fix-step to apply it.

Cache and page speed writes

Ability	What it does
`wppilot/cache-apply-preset`Apply Cache Preset	Applies a named preset to the active cache plugin and purges it, as one change-ledger entry. Undo depends on the driver and captured before-image: W3 Total Cache settings and presets are irreversible in this option-based ledger; external effects are not restored. Keys the plugin does not support are skipped and reported. The aggressive preset contains confirmation-gated keys and is refused without confirm=true; conservative and balanced apply without one. Prefer cache-set-settings with a single key when you are tuning against measurements — a preset moves many settings at once, and if the site gets slower or breaks you will not know which one did it.
`wppilot/cache-begin-experiment`Begin Cache Experiment	Attempts to snapshot settings for the active cache layers and returns an experiment_id with captured and not_captured results. Only captured settings can be restored. Call it before a tuning session; if anything you change afterwards makes the site slower or breaks it, cache-revert-experiment attempts to restore captured settings and purges (a plugin that builds rewrite rules or an on-disk config from its settings may need its settings screen re-saved; see cache-revert-experiment). This spans plugins, which per-change rollback does not: on a site running an asset optimiser in front of a page cache, one id can cover both captured drivers; inspect recovery results for each. It leaves cache configuration unchanged while saving a bounded experiment record. Only the newest five experiments are kept.
`wppilot/cache-purge`Purge Cache	Purges cached HTML across every caching layer detected on this site at once — page-cache plugin, asset optimiser, object cache — because a site that stacks two of them and purges one keeps serving a mix of old and new. `scope` is "all" (default), "url", or "post". A targeted scope on a plugin that only exposes a whole-cache purge widens to a full purge and reports that it did, rather than silently doing nothing. The url must belong to this site. Returns a per-layer result saying exactly which entry point was called, so a layer that could not be purged is visible rather than assumed. This does NOT purge a CDN or WAF edge in front of WordPress (Cloudflare, Sucuri, a host edge) — cache-check-setup lists those under edge_layers and they need their own purge.
`wppilot/cache-set-settings`Set Cache Settings	Writes cache settings using the canonical vocabulary from cache-get-settings, then purges the layer so the change is actually in effect. Pass `settings` as nested groups, e.g. {"images":{"lazyload":true},"page_cache":{"ttl":3600}}. Two tiers: most keys apply straight away, but the ones that routinely break sites — css.combine, css.critical, css.unused_css_removal, css.defer, js.combine, js.defer, js.delay, cdn.enabled, cdn.hosts and page_cache.cache_logged_in — are refused unless confirm=true, and the refusal names exactly which ones. Keys this plugin has no equivalent for are reported as unsupported rather than silently dropped. Writes are logged, but recovery depends on the driver and available before-image. W3 Total Cache settings writes are irreversible in the option-based ledger. A supported restore puts captured option rows back; it does not guarantee regenerated files, external state or the rendered result. Change one thing at a time and re-measure: a batch that makes a site slower or breaks it gives you no way to tell which key did it.
`wppilot/cache-warm`Warm Cache	Requests up to ten URLs of this site so the page cache rebuilds them before anyone measures or visits. Use it immediately after a purge: the first request to a purged URL pays for the whole page build, so a benchmark taken then measures WordPress rendering rather than cache delivery, and reads far worse than the site actually performs. Reports per URL whether the fetch succeeded, how long it took, and whether the response came back reporting a cache HIT — a reported HIT is evidence for that response. A successful fetch or short duration alone does not prove the page was cached. Defaults to the home page when given nothing.
`wppilot/pagespeed-fix-step`Apply One PageSpeed Fix	One measured fix: plans as wppilot/pagespeed-fix-plan does, then sets that one cache key with cache-set-settings (recorded in the change ledger) and purges, checks the page from the server (cache-measure-page status codes, cache-verify-in-browser render suspects), re-runs PageSpeed, and keeps the change only when the performance score did not drop by more than `tolerance` points and its server checks found no new failure. Those checks cannot establish that browser behavior is intact. Otherwise it attempts rollback through wppilot/rollback-change and purges; recovery can fail or be unavailable for a driver without a retained before-image. Reports before and after scores, metrics and checks, the change_id, and why it kept or undid the change. Read status (kept, rolled_back, not_applied, rollback_failed or nothing_to_apply), then check a kept change in a real browser. Needs confirm=true. Takes up to three minutes.

Destructive Cache and page speed calls

Ability	What it does
`wppilot/cache-revert-experiment`Revert Cache Experiment	Attempts to restore settings captured by cache-begin-experiment and purge the detected layers. Use it the moment a tuning step makes things worse: a page that gained console errors, a layout that shifted, a measurement that regressed. Reports which option rows were restored and whether the result matches the snapshot. W3 Total Cache recovery uses its Config object and save path when it was captured, and verifies a fresh read. Other captured option rows are restored directly, so vendor-generated rules or files may require a re-save in the plugin settings screen. Inspect restored, deleted, not_restored, verified and purged_layers, then verify the served result. verified checks captured configuration; it does not certify browser behavior or external state. A cache purge cannot itself be undone.
`wppilot/cache-run-action`Run Cache Action	Runs one of the actions listed by cache-list-actions. Refuses an action whose entry point does not resolve on this install rather than reporting a success nothing performed. Destructive actions — anything that deletes rows rather than rebuilding a cache — require confirm=true, and are NOT reversible: the change ledger restores settings, not deleted revisions or comments. A blocking action runs inline and can take a long time on a large site; a non-blocking one queues work and returns immediately, so re-measure later rather than straight after. `ran` means the entry point was called and did not throw — not that the plugin did the work, which it may decline for its own reasons (a crawler with no sitemap crawls nothing). Confirm through the plugin or by re-measuring.
`wppilot/cache-set-native`Set Native Cache Setting	Writes supported native cache settings by their own keys — the escape hatch for everything outside the canonical model, which covers only what several plugins share. The installed driver determines which native keys are available; names and support vary across versions. Credentials are withheld and credential writes are refused. Read them first with cache-get-settings include_native=true: this ability refuses any key it cannot read back beforehand, so a typo or a key renamed between plugin versions is rejected instead of creating a junk option the plugin ignores. The response reports write_path: plugin_save, mixed or option_direct. LiteSpeed, W3 Total Cache and WP Rocket have native save paths; other drivers use direct option writes, which do not run effects confined to the vendor settings screen. WP Fastest Cache is one such direct-write driver. Verify generated rules and rendered output, and re-save in the vendor screen when needed. W3 Total Cache native writes have no ledger undo. Values are coerced to match the type already stored. Always requires confirm=true: these keys carry no risk tiering, no validation beyond the plugin's own, and no guarantee GoBuildWP understands what they mean.