Caching and page speedPro
Autoptimize MCP: tuning an asset optimiser that has no page cache
Autoptimize MCP work starts from what the plugin is: an asset optimiser that aggregates, minifies and defers CSS and JavaScript and caches the resulting bundles, with no page cache of its own. Through GoBuildWP Pro an AI agent can change those switches and two image options, clear the bundle cache, and purge whatever page cache sits next to it at the same moment, then verify that stored pages and external delivery layers no longer reference missing bundles.
autoptimize- Layer
- asset
- Declared purge scopes
all- Shared keys
- 8
- Detected by
- constant AUTOPTIMIZE_PLUGIN_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.
Data model
Loose option rows plus one image array
Most Autoptimize switches are option rows of their own: autoptimize_css, autoptimize_css_aggregate, autoptimize_css_defer, autoptimize_js, autoptimize_js_aggregate and autoptimize_js_defer_not_aggregate. A ticked box is stored as the string on and an unticked one as empty, matching what its own form posts. Image settings are different: they sit inside the autoptimize_imgopt_settings array under generated field names, lazy loading as autoptimize_imgopt_checkbox_field_3 and next-gen formats as field 5.
The bundles live on disk, by default in wp-content/cache/autoptimize/ according to its documentation, and one bundle is shared by many pages. That is why a purge here is all or nothing.
No page_cache setting is mapped, deliberately. Offering one would invite an agent to enable caching on a plugin with nothing to enable.
Mapped switches are written with update_option() to their own rows in Autoptimize's on-or-empty convention; the two image switches are set inside autoptimize_imgopt_settings rather than as rows of their own.
Shared key → Autoptimize setting
css.minify → autoptimize_csscss.combine → autoptimize_css_aggregatecss.defer → autoptimize_css_deferjs.minify → autoptimize_jsjs.combine → autoptimize_js_aggregatejs.defer → autoptimize_js_defer_not_aggregateimages.lazyload → imgopt.autoptimize_imgopt_checkbox_field_3images.next_gen → imgopt.autoptimize_imgopt_checkbox_field_5
Option rows
autoptimize_imgopt_settingsautoptimize_cssautoptimize_css_aggregateautoptimize_css_deferautoptimize_jsautoptimize_js_aggregateautoptimize_js_defer_not_aggregate
Other plugins
Autoptimize always has company
- Its documentation recommends pairing it with a page cache, and KeyCDN states Cache Enabler is compatible with it. On such a stack check-setup lists two layers, one of kind asset.
- Autoptimize's clear-all fires autoptimize_action_cachepurged and tries to flush known page caches, including W3TC, SiteGround Speed Optimizer and WP Fastest Cache.
- WP Rocket conflicts with it only when both minify or aggregate the same files; Super Page Cache for Cloudflare lists it as safe, and NitroPack names it among plugins it cannot share a site with.
Abilities
The cache abilities on an asset-only layer
| Ability | What it does here | Undo and limits |
|---|---|---|
cache-purge | Calls autoptimizeCache::clearall(). A url or post scope widens to that full clear, and the result says it widened, because a shared bundle cannot be cleared for one page. | Irreversible and stateless; the page cache beside it is purged in the same call. |
cache-get-settingscache-set-settings | Covers CSS and JS minify, aggregation, inline-and-defer CSS, non-aggregated JS defer, lazy loading and next-gen images. | Aggregating either type, css.defer and js.defer need confirm. The ledger snapshots every mapped row, not only the one written, because switching aggregation off resets the defer flag that only applies while aggregating; rollback-change restores both. |
cache-set-native | Reaches the rest of Autoptimize's options by name once include_native has listed them. | Always confirm; the row written is added to the before-image. |
cache-list-presetscache-apply-preset | Conservative sets lazy loading only. Balanced adds next-gen images and minification. Aggressive adds aggregation and JS defer. Page-cache keys are skipped and listed. | Aggressive needs confirm. |
cache-check-setupcache-measure-pagecache-warmcache-verify-in-browser | Render-blocking stylesheet and head-script counts are the numbers Autoptimize moves; hit or miss belongs to the neighbouring page cache. | Read-only apart from warming. |
cache-list-actionscache-run-actioncache-begin-experimentcache-revert-experiment | No actions are declared for Autoptimize. An experiment takes its rows and the page cache's in one id. | Revert needs confirm; inspect restored/deleted/not_restored/verified/purged_layers and any not_captured storage. A separate cache-purge reports per-layer details. Purge availability is layer-specific. |
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.
Worked example
Aggregate CSS, keep it only if the menu still opens
Expected outcome to verify on the installed stack; this sequence has not been recorded as a runtime test.
Fewer stylesheet requests if the page still renders correctly. If the menu breaks, revert the captured settings and inspect storage verification and the purged-layer count, then check several pages for missing bundles and rendering failures, including relevant external cache layers. Successful storage restoration alone does not establish bundle freshness.
Inspect coupled or reset defer flags and compatible image-CDN setup. After write or revert, check several pages for missing bundles, correct rendering and required external-layer purges.
Combine the site's CSS with Autoptimize, but undo it if the mobile menu or any hover state breaks.
wppilot/cache-begin-experimentWriteOne id covering Autoptimize's rows and the page cache's settings.
wppilot/cache-measure-pageReadBaseline count of render-blocking stylesheets and the HTML weight.
wppilot/cache-set-settingsWriteAfter approval, css.combine with confirm writes autoptimize_css_aggregate as on and purges the selected Autoptimize layer. Use a separate cache-purge for other layers and inspect each layer result.
wppilot/cache-warmWriteRequests the measured page so it is built again with the new bundle.
wppilot/cache-verify-in-browserReadSupplies the checks: console clean, menu opens, open-state styles present.
A suggested sequence from the ability reference, not a recorded run.
Autoptimize beyond the switches
A fresh Autoptimize install has no settings rows yet
Autoptimize only writes its option rows the first time someone saves its settings screen. On a site where it was activated and never configured, there is no autoptimize_css row at all. GoBuildWP's canonical read handles that: each mapped switch declares Autoptimize's default, so an absent row reads as the default in use rather than as a feature the plugin lacks. An agent will correctly report minification as off on such a site instead of claiming Autoptimize cannot minify.
The native layer is stricter. cache-set-native refuses any key it cannot read back first, which is what stops a typo from creating a junk option. On a never-saved install most of Autoptimize's own keys do not exist yet, so save the settings screen once in wp-admin before asking the agent to reach anything outside the eight shared switches. After that, include_native lists the plugin's full set of autoptimize rows, and the agent can see what a previous developer configured that the shared vocabulary does not name.
When aggregated JavaScript breaks one feature
The common Autoptimize failure is not a blank page. It is one slider, cookie banner or form that stops working after JavaScript is aggregated, because a script now runs in a different order or before something it depends on. Turning js.combine off fixes it but gives up the gain everywhere. The usual Autoptimize answer is an exclusion for the script that misbehaves, and that is a native setting, not a shared key.
A sensible agent session starts an experiment, reads the native rows to find the exclusion setting by its real name, and adds one script at a time with cache-set-native and confirm. A native write can purge the selected Autoptimize layer; refresh any page cache beside it with a separate cache-purge and inspect the per-layer results. Then warm the affected page and run the browser checks to see whether the exclusion fixed the symptom before trying another. If the list grows long, that is a sign aggregation is not worth it on this theme, and switching it off cleanly is the better result.
- Write down which page and which interaction broke; a home page check will not catch a checkout script.
- Native values are coerced to the type already stored, and booleans are handed to the driver, which writes Autoptimize's own on-or-empty strings.
- Exclusions survive a later preset because presets only touch shared keys.
Choosing Autoptimize settings by what the measurement can see
cache-measure-page reports render-blocking stylesheets and head scripts, HTML weight, images without dimensions and preloaded fonts. Those are the numbers Autoptimize moves, so they are the honest before-and-after for this plugin. Hit or miss in the same report belongs to whichever page cache sits next to Autoptimize, not to Autoptimize itself. Neither number is a Lighthouse score; field metrics such as LCP and CLS still need a real browser.
Questions
Autoptimize questions
Does Autoptimize cache pages?
No. It caches optimised CSS and JS files. A page cache has to come from another plugin or the host, and the agent tunes that one separately.
My site looked broken after the agent purged Autoptimize. What happened?
Autoptimize's FAQ gives the usual cause: cached pages still referencing deleted bundles. cache-purge also asks the page cache to clear and reports each layer's result. If that report shows the page layer purged and pages still reference old bundles, check any edge cache in front of WordPress, which needs its own purge, along with browser caching and any page cache the report did not list.
Can the agent clear Autoptimize for a single URL?
No such entry point exists, because bundles are shared. A targeted request becomes a full clear and the result states that.
Will the agent's purges stop the cache folder growing?
Only when a purge runs. Autoptimize's FAQ explains it does not prune its cache automatically, because deleting files could break cached pages that still reference them.
Limits
Boundaries on an Autoptimize site
- Asking this layer to enable caching, set a TTL or preload does nothing; those keys are reported as unsupported.
- Critical CSS, CDN and font options have no shared key here and stay native or in the plugin screen.
- Purges are site-wide by nature and cannot be undone; settings writes can.
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.
Autoptimize is a separate product; no partnership or endorsement is implied.