Caching and page speedPro
SiteGround Speed Optimizer MCP: one option per setting, a cache on the host
SiteGround Speed Optimizer MCP access through GoBuildWP Pro lets an AI agent change the plugin's switches for dynamic caching, Memcached, browser caching, minification, lazy loading and WebP, then purge through sg_cachepress_purge_cache. The catch is where the cache lives: its dynamic cache and Memcached run on SiteGround's own servers, so the same switch can be meaningful on one host and inert on another.
sg_optimizer- Layer
- page
- Declared purge scopes
allurl- Shared keys
- 11
- Detected by
- constant SiteGround_Optimizer\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
A row for each switch, a cache outside WordPress
Speed Optimizer stores each setting in its own option named siteground_optimizer_ plus the setting, holding the string 1 or 0; GoBuildWP writes the same strings because the plugin's readers compare against them. A setting nobody has touched has no row at all, which on a fresh install is all of them, so each mapped key declares a default and an absent row reads as that default rather than as a missing feature.
SiteGround's listing reserves the dynamic cache and Memcached for SiteGround servers; file-based caching, asset optimisation and image work run elsewhere too. The dynamic cache sits at SiteGround's edge, so a settings change is only fully live once that cache is purged.
URL exclusions and bypass rules are documented as PHP filters such as sgo_exclude_urls_from_cache and sgo_bypass_cookies. Those are code, not settings, and fall outside anything the cache abilities write.
Each mapped key is written with plain option updates to its own siteground_optimizer_ row, the same storage the plugin's settings screen uses, and the purge bridge then clears the host cache so the change is served.
Shared key → Speed Optimizer (SiteGround) setting
page_cache.enabled → siteground_optimizer_enable_cacheobject_cache.enabled → siteground_optimizer_enable_memcachedbrowser_cache.enabled → siteground_optimizer_enable_browser_cachingcss.minify → siteground_optimizer_optimize_csscss.combine → siteground_optimizer_combine_cssjs.minify → siteground_optimizer_optimize_javascriptjs.combine → siteground_optimizer_combine_javascriptjs.defer → siteground_optimizer_optimize_javascript_asyncimages.lazyload → siteground_optimizer_lazyload_imagesimages.lazyload_iframes → siteground_optimizer_lazyload_iframesimages.next_gen → siteground_optimizer_webp_support
Option rows
siteground_optimizer_enable_cachesiteground_optimizer_enable_memcachedsiteground_optimizer_enable_browser_cachingsiteground_optimizer_optimize_csssiteground_optimizer_combine_csssiteground_optimizer_optimize_javascriptsiteground_optimizer_combine_javascriptsiteground_optimizer_optimize_javascript_asyncsiteground_optimizer_lazyload_imagessiteground_optimizer_lazyload_iframessiteground_optimizer_webp_support
Worked example
Switch on Memcached and find out whether it did anything
Expected outcome to verify on the installed stack; this sequence has not been recorded as a runtime test.
On a SiteGround server, Memcached serving objects and a before-and-after comparison. Anywhere else the row says 1 and nothing changes; the report names that as a hosting task rather than calling it a win.
Measure a baseline before writing; warm the URL and measure again, then inspect expected content. A SiteGround detector label does not prove Memcached is serving. fonts.host_locally reports unsupported: optimize_web_fonts inlines the Google Fonts stylesheet but font files still come from fonts.gstatic.com.
Turn on Memcached in Speed Optimizer and tell me honestly whether the site got faster.
wppilot/cache-check-setupReadLists Speed Optimizer, whether a persistent object cache is already in use, and any edge layer answering the request.
wppilot/cache-begin-experimentWriteSnapshots every siteground_optimizer_ row before the change.
wppilot/cache-set-settingsWriteobject_cache.enabled true writes siteground_optimizer_enable_memcached as 1, then purges.
wppilot/cache-measure-pageReadCompares time to first byte against the baseline on the same URL after warming.
wppilot/cache-verify-in-browserReadIts blocked_by_environment list says when an object cache is missing because the host has not provided one.
A suggested sequence from the ability reference, not a recorded run.
Abilities
Where each ability meets Speed Optimizer
| Ability | What it does here | Undo and limits |
|---|---|---|
cache-purge | sg_cachepress_purge_cache() with no argument for everything, or with a URL for one page. There is no post entry, so a post-scoped purge falls back to the whole cache and says so. | Cannot be undone, and another CDN in front still needs its own purge. |
cache-get-settingscache-set-settings | Mapped rows cover the dynamic cache, Memcached, browser caching, CSS and JS minify and combine, async JavaScript for js.defer, image and iframe lazy loading, and WebP. fonts.host_locally reports unsupported: Speed Optimizer's web-font option combines and inlines the Google Fonts stylesheet, but the font files still load from fonts.gstatic.com. | Combining CSS, combining JS and async JS are gated. Each touched row is in the before-image, so rollback-change restores it. |
cache-set-native | Any other siteground_optimizer_ row can be written by name after include_native lists it. | Confirm every time; a row created by a native write is removed again on experiment revert. |
cache-list-presetscache-apply-preset | Conservative enables caching, browser caching and both lazy-load switches; balanced adds WebP and minify; aggressive adds combining and async JS. | Aggressive needs confirm. |
cache-check-setupcache-measure-pagecache-warmcache-verify-in-browser | Detection, response timing with cache headers, warming, and browser checks including environment blocks. | Read-only apart from warming. |
cache-list-actionscache-run-actioncache-begin-experimentcache-revert-experiment | No actions are declared for Speed Optimizer. Experiments hold every row it has written. | Revert is confirmation-gated. |
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
Speed Optimizer and its neighbours
- Automatic purge on content updates is on by default in Speed Optimizer, and GoBuildWP's own purge-after-write adds to it for edits an agent makes.
- Autoptimize's clear-all calls sg_cachepress_purge_cache(), and FlyingPress disables conflicting optimisations in Speed Optimizer on its own.
- WP Fastest Cache names Speed Optimizer among the caches to disable before using it.
Unsaved switches, host headers and gated toggles
Speed Optimizer settings that have never been saved have no row
SiteGround Speed Optimizer MCP work runs into one storage quirk early: the plugin creates a siteground_optimizer_ row only when a setting is first saved. For the switches GoBuildWP maps, an absent row reads as its default, so cache-set-settings can turn dynamic caching, Memcached or WebP support on even on a fresh install. cache-set-native has no such defaults. It refuses any key it cannot read back first, so an unmapped Speed Optimizer setting that has never been saved comes back under unknown_keys instead of being created.
The fix is to toggle that setting once in Speed Optimizer's own screen, which creates the row, and then let the agent change it by name. The native dump lists only rows that exist, so a setting missing from it is either unsaved or not a Speed Optimizer option at all. Native writes on this plugin are direct option updates, and the write_path field in the response says so.
Telling SiteGround's host cache apart from Speed Optimizer's own work
On SiteGround hosting the HTML can come from the host's dynamic cache before WordPress runs at all. cache-measure-page reports every cache header it recognises verbatim, x-proxy-cache and age among them, across repeated requests from the server itself. Which header SiteGround's layer sets on your plan should be confirmed on the real site; once you know it, a HIT on the second run is the evidence that the host cache answered.
Two readings deserve a second look. Cache headers present but never a HIT suggests the layer saw the request and declined it; on Speed Optimizer one common cause is an exclusion set through its PHP filters, which no ability writes, though a cookie, a query string or the dynamic cache being off can do the same. No recognised header at all can mean the site is not on SiteGround's servers, where only the plugin's file-based features apply, but it can also mean the server fetch took a route that skipped the host cache or that the header name differs on your plan, so confirm the hosting with SiteGround before concluding. Check runs[].fetched_via as well: a run that fell back to the local interface skipped the path a visitor's request takes.
Which Speed Optimizer toggles need a yes before they move
Three Speed Optimizer switches are gated: siteground_optimizer_combine_css, siteground_optimizer_combine_javascript, and siteground_optimizer_optimize_javascript_async, which is what js.defer lands on. cache-set-settings refuses them without confirm=true, even to switch them off, because the gate is on the key rather than the value, and the refusal names the key. Under Read Only no settings ability writes at all. Under Production Safe the ungated switches apply directly, are stored as the strings 1 and 0 the plugin compares against, and land in the ledger for rollback-change.
Prompts that fit this plugin, with the reference for each ability in the cache module docs:
- "Read every siteground_optimizer_ row and tell me which mapped switches are still sitting on their defaults."
- "Measure the homepage twice and tell me whether SiteGround's cache or WordPress answered the second request."
- "Turn on lazy loading for images and iframes, then give me the browser checks for the hero image."
Questions
Speed Optimizer (SiteGround) questions
Does the agent's control work if my site is not hosted at SiteGround?
The settings still write and the file-based cache and optimisations apply, but the dynamic cache and Memcached exist only on SiteGround servers.
Why did purging one post clear the whole cache?
Speed Optimizer exposes a whole-cache purge and a URL purge, but nothing keyed by post. GoBuildWP widens rather than leaving a stale page, and the result says it did.
Can the agent exclude a URL from SiteGround's dynamic cache?
Not through the shared settings, which have no exclusion key for this plugin. SiteGround documents exclusions as PHP filters, and the cache abilities do not write code.
SiteGround documents performance controls in its own AI agent. GoBuildWP's local driver has a separate capability boundary; hosting-side actions remain subject to the host's tools and account access. SiteGround AI performance guide
Limits
Honest limits on SiteGround
- Dynamic caching and Memcached need SiteGround servers; elsewhere those rows change without effect.
- Post-scoped purges widen to a full purge.
- There is no local font hosting to map. siteground_optimizer_optimize_web_fonts stays in the native read and can be written there by name once its row exists.
- SiteGround's wp sg commands are not used; GoBuildWP calls the PHP purge function and writes options.
- Settings writes can be rolled back; purges cannot.
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.
Speed Optimizer (SiteGround) is a separate product; no partnership or endorsement is implied.