Caching and page speedPro
Perfmatters MCP: its own option keys, saved by name and checked in a browser
Perfmatters MCP access in GoBuildWP Pro is deliberately narrow. The plugin disables scripts, delays JavaScript and strips unused CSS, but it keeps no page cache, so an agent has nothing to purge here. Its settings are reachable by their own key names, each write needs confirmation, and because nobody has verified what those keys mean beside other plugins, no preset or risk tier applies. Every change is one to check in a real browser.
perfmatters- Layer
- asset
- Declared purge scopes
- No purge entry point declared
- Shared keys
- None
- Detected by
- constant PERFMATTERS_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.
Limits
Read these before the first write
- The inspected evidence did not establish Perfmatters native-key semantics for this driver. No key is mapped to the shared vocabulary; inspect the installed plugin and its documentation before a native write.
- Every write goes through cache-set-native with confirm. There is no warning that a key is risky, because nothing has been classified; treat script-disabling and delay settings as the sharpest ones.
- GoBuildWP has no entry point for clearing Perfmatters' used-CSS files. Perfmatters documents wp perfmatters clear-used-css and Perfmatters\CSS::clear_used_css() for that.
- Writes are undoable: the ledger snapshots the option row each key lives in, and rollback-change restores it.
Data model
Three option rows, addressed as option:key
GoBuildWP reads Perfmatters from perfmatters_options, perfmatters_tools and perfmatters_script_manager, and names every setting as row:key so reads and writes route to the right row. A reference to any row outside those three is refused, which is what keeps this driver from becoming a way to edit unrelated WordPress options.
Perfmatters does write files: its documentation puts generated used CSS in wp-content/cache/perfmatters/ per domain. Those are optimisation output, not a page cache, and GoBuildWP's purge map records Perfmatters as having nothing to purge rather than leaving that to look like a failure.
For an agent the practical meaning is that GoBuildWP can show and change any key that exists, but it cannot say what the key does. The key has to be identified from its name and value in the native read, and the effect confirmed on the page.
Option rows
perfmatters_optionsperfmatters_toolsperfmatters_script_manager
Abilities
What each cache ability means with Perfmatters
| Ability | What it does here | Undo and limits |
|---|---|---|
cache-get-settingscache-set-native | include_native returns the three rows in row:key form; a write names one of those keys and is refused if it cannot be read back first, so a mistyped or renamed key never creates a junk option. | Confirm on every call. Values are coerced to the type already stored. |
cache-set-settingscache-list-presetscache-apply-preset | With an empty shared map, every canonical key reports as unsupported and all three presets set nothing here. | These abilities change nothing on Perfmatters; use native keys instead. |
cache-purgecache-warm | Perfmatters is skipped in the purge fan-out. The page cache running beside it is still purged and can be warmed. | Stateless; no undo exists or is needed. |
cache-list-actionscache-run-action | No Perfmatters actions are declared. | Nothing to run. |
cache-check-setupcache-measure-pagecache-verify-in-browser | Setup lists Perfmatters as an asset layer without a canonical map. The measurement counts head scripts and blocking stylesheets; the browser checks catch an undefined jQuery or a console error after a script was delayed or removed. | All read-only. |
cache-begin-experimentcache-revert-experiment | An experiment records all three Perfmatters rows plus the page cache's settings; a revert also removes rows that did not exist at the snapshot. | Revert requires confirm and discards changes that worked too. |
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.
Other plugins
Perfmatters beside a cache plugin
- Perfmatters describes itself as designed to work alongside your caching plugin, and publishes settings guides for LiteSpeed Cache and WP Fastest Cache.
- Its recommended clearing order runs theme, third-party plugins, Perfmatters, host, then CDN.
- FlyingPress disables conflicting optimisations in Perfmatters automatically, and NitroPack lists Perfmatters among plugins it cannot run with.
Worked example
Find and switch off a delay setting
Expected outcome to verify on the installed stack; this sequence has not been recorded as a runtime test.
Check whether the widget now loads before interaction on each affected page. If the symptom remains, inspect the saved key, loaded assets, other optimisers and delivery layers before deciding whether the setting was involved. Restore the previous row before testing another candidate.
Preserve complete arrays during native-key edits. Verify stored values, then test the actual widget in a browser and inspect used-CSS regeneration separately.
Something in Perfmatters is delaying the chat widget. Find the setting and turn it off.
wppilot/cache-check-setupReadShows Perfmatters as an asset layer, native access only, and which page cache sits beside it.
wppilot/cache-get-settingsReadWith include_native, returns every perfmatters_options key and value so the delay-related entries can be identified by name.
wppilot/cache-begin-experimentWriteCaptures the three rows before anything moves.
wppilot/cache-set-nativeConfirm firstAfter the owner confirms the key, writes it as row:key with confirm; the ledger stores the row first.
wppilot/cache-purgeWriteClears the neighbouring page cache so the page is rebuilt without the delay.
wppilot/cache-verify-in-browserReadReturns the checks for a console error and a responding widget on that URL.
A suggested sequence from the ability reference, not a recorded run.
Perfmatters rows, read whole and changed one key at a time
Pointing Perfmatters MCP calls at the perfmatters driver, not the page cache
Perfmatters MCP calls rarely run on a site with Perfmatters alone. GoBuildWP classes it as an asset layer, and there is usually a page cache beside it. When cache-get-settings or cache-set-native is called without a driver, GoBuildWP picks the layer that has a shared settings map, and Perfmatters has none, so an unqualified call quietly answers for WP Rocket, LiteSpeed Cache or whichever page cache is present. Every Perfmatters read and write should name driver perfmatters, and the driver field in the response is worth checking before anything is approved.
Native keys travel as row:key, for example a key inside perfmatters_options or perfmatters_script_manager. The merge happens at the top level of that row only. When a key holds a nested array, as script manager entries tend to, the value sent replaces the whole array, so the agent has to send back the complete structure it read with one entry changed, never a fragment of it. The dump also carries native_complete: when it is false the rows were larger than the read cap, and a key the agent did not see must not be written from a guess.
A staging pass before any perfmatters_script_manager write
The script manager is where a wrong value unloads a script on pages nobody happens to be looking at, so the first run belongs on a staging copy with the same theme, plugins and Perfmatters licence as production. Keep reference values and inspect the experiment capture before each setting change. Recovery applies only to captured restorable settings; purge and warm have no state to restore.
- cache-check-setup: confirm Perfmatters is listed as an asset layer with native access only, and note which page cache and edge layers sit beside it.
- cache-get-settings with driver perfmatters and include_native: keep the three rows as the reference copy.
- cache-begin-experiment: snapshot every layer, so one revert also restores the page cache if a later step touches it.
- cache-set-native with confirm: change one row:key and nothing else.
- cache-purge, then cache-warm on the affected URLs: Perfmatters itself is skipped, but the page cache in front still holds pages built before the change.
- cache-verify-in-browser on a page that loads the affected script, then the console and interaction checks it returns.
- cache-revert-experiment, or rollback-change on that single entry, the moment a check fails.
What the safety profile and a WordPress role allow on Perfmatters
The cache abilities run only for a user who can manage options, or a super admin on multisite, and every one of them is Pro. Under the Read Only safety profile an agent can still list the layers, dump the Perfmatters rows, measure a page and collect the browser checks. That shows the stored Perfmatters settings and how the page is delivered from the server; what those settings do in a real browser still needs the browser checks to be run by a person. It cannot write, purge or warm there.
cache-set-native is annotated destructive, so on Production Safe and on Developer Full Access alike the call is held until it carries an explicit confirmation, and the ability demands confirm=true of its own accord as well. That double gate suits a plugin whose keys GoBuildWP has never classified: no Perfmatters key will ever show up in risky_keys, because none has been tiered. The GoBuildWP security model explains how profiles are enforced at dispatch.
Perfmatters requests worth typing, and work to keep in its own screen
The agent earns its place reading and diffing the three rows, pointing at entries that look related to a symptom, and putting a row back. Choosing which script to unload on which page is easier in Perfmatters' own script manager, where assets are listed against the page you are viewing. Native writes are best kept for undoing or copying a change you already understand.
- "Dump perfmatters_options and perfmatters_script_manager with driver perfmatters and tell me which entries mention delay or defer. Change nothing."
- "Start an experiment, switch off the one key I name in perfmatters_options, and give me the browser checks for the contact page."
- "The checkout lost its payment button after the Perfmatters change you made. Roll that change back with rollback-change and purge the page cache."
Questions
Perfmatters questions
Why can't the agent apply a speed preset to Perfmatters?
Presets are written in the shared vocabulary, and no Perfmatters key has been verified to mean the same as a key elsewhere. Without that, a preset would be a guess.
Does the agent's purge clear Perfmatters' used CSS?
No. GoBuildWP has no purge entry for Perfmatters. Clear used CSS from Perfmatters or with its wp perfmatters clear-used-css command.
Could an agent break my site through the script manager?
Yes. Every native write requires confirm=true, which the AI client can supply by default. Use the configured human-approval mode when a person must approve, inspect experiment coverage, and run the browser checks after each change.
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.
Perfmatters is a separate product; no partnership or endorsement is implied.