Caching and page speedPro
WP Fastest Cache MCP: switches in the WpFastestCache row, purged through its hooks
WP Fastest Cache MCP support in GoBuildWP Pro works on one JSON option row that also carries the plugin's exclusion rules and CDN setup, so every write merges into it instead of replacing it. An AI agent can toggle the cache itself and the minify, combine, render-blocking and lazy-load switches, clear the whole cache, one URL or one post through the plugin's own hooks, and undo a switch that broke the page. Browser caching, mobile caching, preload and logged-in handling stay in the plugin's settings screen, because WP Fastest Cache only applies them when that screen is saved.
wp_fastest_cache- Layer
- page
- Declared purge scopes
allurlpost- Shared keys
- 7
- Detected by
- class WpFastestCache
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
The menu stopped working after Combine JS
Expected outcome to verify on the installed stack; this sequence has not been recorded as a runtime test.
A working menu served from a rebuilt cache, and a ledger entry that can put Combine JS back if the owner wants to try again with exclusions. If the menu still fails, check purge results, other optimizers, loaded assets and browser state. Continued failure does not prove Combine JS is unrelated.
Logged-in, mobile, browser caching and preload report unsupported here; set them in the plugin's own screen and save so its .htaccess rules and preload schedule are built. An unticked box is an absent key in the WpFastestCache row, and an absent row and an empty JSON row are different snapshot states; inspect restored/deleted results and generated server rules.
Since someone ticked Combine JS in WP Fastest Cache the mobile menu does nothing. Turn it off and check the menu.
wppilot/cache-get-settingsReadReports js.combine as on, read from wpFastestCacheCombineJs, and lists it among the risky keys.
wppilot/cache-set-settingsWritejs.combine set to false. Because the gate is on the key, not the value, even switching it off goes in with confirm after the owner agrees.
wppilot/cache-purgeWriteScope all fires wpfc_clear_all_cache with true, the flag WP Fastest Cache documents for removing minified files too.
wppilot/cache-warmWriteRequests the homepage so the menu can be tested on a newly cached copy.
wppilot/cache-verify-in-browserReadGives the checks: jQuery defined, no console error, menu toggles on tap.
A suggested sequence from the ability reference, not a recorded run.
Abilities
The cache abilities on WP Fastest Cache
| Ability | What it does here | Undo and limits |
|---|---|---|
cache-purge | Scope all dispatches wpfc_clear_all_cache with true; url dispatches wpfc_delete_cache_by_url; post dispatches wpfc_delete_cache_by_post_id. Each fires only when has_action shows the plugin is listening. | Stateless, so nothing to roll back. |
cache-get-settingscache-set-settings | Mapped from GoBuildWP Pro 1.12.4: the cache status switch, minify and combine for CSS and JS, render-blocking JS for js.defer, and lazy load. A ticked box is written as the literal on and an unticked one by removing its key, because the plugin treats any stored value as ticked. | page_cache.cache_logged_in, page_cache.mobile_separate, browser_cache.enabled and preload.enabled report unsupported. Both combine switches and render-blocking JS need confirm in either direction. The whole row is the before-image for rollback-change. |
cache-set-native | Reaches exclusion rules, CDN entries and anything else in the row by its own key. | Confirm required; the row is snapshotted first. |
cache-list-presetscache-apply-preset | Conservative turns on caching and lazy load. Balanced adds CSS and JS minify; aggressive adds combining and render-blocking JS. | Preset keys with no WP Fastest Cache equivalent, browser caching and preload among them, come back under unsupported. Aggressive refuses without confirm. |
cache-check-setupcache-measure-pagecache-warmcache-verify-in-browser | Detection, timing and cache status, warm requests, and the list of browser checks for the page just changed. | No settings writes. cache-warm requests pages from the site, which can write fresh cache files. |
cache-list-actionscache-run-actioncache-begin-experimentcache-revert-experiment | No actions are declared, and preload is left to the plugin's own screen. An experiment captures the WpFastestCache row whole. | 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.
Limits
Edges of the WP Fastest Cache driver
- page_cache.cache_logged_in reports unsupported. WP Fastest Cache never caches pages for signed-in users, and its wpFastestCacheLoggedInUser box means "don't show the cached version for logged-in users", so neither setting of it matches the shared key.
- Mobile caching, browser caching and preload report unsupported too. Each takes effect only through work the settings screen does when saved (the .htaccess rules and the preload schedule), so a row write would read back as on while the site kept its old behaviour. Turn them on in the plugin and save.
- Expiry is a list of per-path rules rather than one lifetime, so no TTL key is mapped; the rules stay visible in the native read.
- Render-blocking JS and lazy load only act when WP Fastest Cache Premium is installed, and its listing names minify JS as Premium too. Without Premium the value is stored and reads back as on while the page does not change, so check the page itself.
- The plugin relies on mod_rewrite and a writable .htaccess, according to its listing; GoBuildWP never writes .htaccess itself. On Nginx its documentation says Gzip and browser caching must be configured by hand.
Data model
Everything in the WpFastestCache row
All settings live in a single option row, WpFastestCache, stored as the JSON of the settings form. A ticked checkbox holds the string on and an unticked one has no key at all, because the plugin tests most boxes only for presence; storing an empty string would read as ticked. GoBuildWP Pro 1.12.4 writes off by removing the key. The same row holds exclusion rules and CDN configuration that GoBuildWP does not model.
That shape is why writes merge. The driver changes only the keys it was given and keeps everything else in the object; replacing the row would silently delete exclusions and CDN settings the owner set by hand.
Shared key → WP Fastest Cache setting
page_cache.enabled → wpFastestCacheStatuscss.minify → wpFastestCacheMinifyCsscss.combine → wpFastestCacheCombineCssjs.minify → wpFastestCacheMinifyJsjs.combine → wpFastestCacheCombineJsjs.defer → wpFastestCacheRenderBlockingimages.lazyload → wpFastestCacheLazyLoad
Option rows
WpFastestCache
Other plugins
Other plugins on the same site
- WP Fastest Cache calls running several caching plugins at once very inconvenient and names LiteSpeed Cache, WP-Optimize, W3 Total Cache, WP Super Cache, SiteGround Speed Optimizer and Breeze as ones to disable.
- Perfmatters publishes a guide to its settings alongside WP Fastest Cache, and Autoptimize's clear-all tries to flush WP Fastest Cache's pages.
Unticked boxes, the Submit button and post purges
Ticking a WP Fastest Cache box that is currently unticked
WP Fastest Cache MCP writes run into the way the plugin stores an unticked box: it leaves the key out of the WpFastestCache row altogether, and the plugin treats almost any key that is present as ticked. For the seven switches GoBuildWP Pro 1.12.4 maps, that absence reads as off, cache-set-settings can turn them on, and turning one off removes its key. cache-set-native cannot add a key. It refuses any key it cannot read back first, so an unmapped option that has never been ticked comes back under unknown_keys rather than being added.
Tick it once in the plugin's settings and save, and the key appears in the native dump with the literal value on; from then the agent can switch it by name, sending false to untick it. Each write also purges the layer through wpfc_clear_all_cache unless purge is set to false, which is worth doing when several keys go in one after another and a single purge can close the batch.
WP Fastest Cache features that wait for its own save
cache-set-native reports write_path option_direct for this plugin, and cache-set-settings writes the same JSON row the same way, so WP Fastest Cache's own save handler does not run. That handler is where the plugin writes its .htaccess rules for mobile and browser caching and schedules preload, and GoBuildWP never writes .htaccess. That is why, from Pro 1.12.4, browser_cache.enabled, page_cache.mobile_separate and preload.enabled report unsupported on this plugin instead of reading back as on while nothing changed.
Switch those three in WP Fastest Cache's own screen and save. For browser caching, confirm a Cache-Control header on a static asset in the browser's network panel afterwards. On a LiteSpeed or Apache host with no .htaccess in the WordPress root, cache-verify-in-browser lists browser-cache headers under blocked_by_environment, because the rule the plugin writes there is never read.
How GoBuildWP's own edits clear WP Fastest Cache, and prompts to try
When an agent edits a post through any GoBuildWP write, purge-after-write collects that post and, at the end of the request, dispatches wpfc_delete_cache_by_post_id for it if WP Fastest Cache is listening on that hook; otherwise the layer widens to wpfc_clear_all_cache and the result says so. Under Read Only none of this runs, because purges are writes. Production Safe permits the purge subject to per-ability and approval rules, while gated switches still need confirm=true.
Every cache ability is Pro on GoBuildWP's side, and WP Fastest Cache Premium is a separate licence for that plugin's premium features; Free vs Pro shows where GoBuildWP draws its own line.
- "Which WP Fastest Cache options are ticked, and which unmapped keys exist in the row? Read only."
- "Turn on Minify CSS, purge, and give me the browser checks for the homepage."
- "I edited the About page. Make sure WP Fastest Cache serves the new version and warm it."
Questions
WP Fastest Cache questions
How can I tell WP Fastest Cache served a page?
Its documentation says to load the page twice and look for the WP Fastest Cache file was created comment at the bottom of the source. The agent's measurement adds timing and headers.
Does the agent's full purge also delete minified CSS and JS?
It fires the clear-all hook with true, which WP Fastest Cache documents as including minified files.
Did WP Fastest Cache changes made through older GoBuildWP Pro versions apply?
No. Before Pro 1.12.4 the driver wrote to a WpFastestCacheOptions row the plugin never reads, so those writes reported success and changed nothing; the leftover row is ignored. Read the settings again after updating and switch what you still want.
Why won't the agent set a cache timeout?
Timeouts in WP Fastest Cache are rules per path or prefix, not one number, so there is no single value to map. Edit the rules natively or in the plugin screen.
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 Fastest Cache is a separate product; no partnership or endorsement is implied.