xSpeed Cache vs GoBuildWP: one optimizer or a stack control layer?

What xSpeed Cache's MCP server offers, per its listing

We re-read xSpeed Cache's WordPress.org listing on 3 October 2026, when it showed version 1.3.7, WordPress 6.0 and PHP 7.4 as minimums. It is a full cache plugin first: page caching with a static-file rewrite, minification and file combining, deferred and delayed JavaScript, lazy loading, font optimisation, browser cache headers, a preloader, a Redis or Memcached object cache, CDN support with Cloudflare, and database cleanup. The listing marks those as free and the AI-powered site audit as Pro.

Its MCP server exposes purge, preloader status, a score run, settings reads and writes, generate_critical_css, get_cache_status and optimize_site. Clients connect through OAuth discovery with dynamic client registration, and a read-only connection can read status through every tool while writes are refused. The listing describes optimize_site as measuring the site, applying recommended settings one at a time, rechecking the page after each change and reverting anything that breaks it. We have not run that loop ourselves.

Where xSpeed Cache is ahead

• It is the engine. Installing it gives a site page cache, asset optimisation and object caching; GoBuildWP gives a site none of those.
• The tuning loop is built in. optimize_site decides, applies and reverts on its own, so an assistant needs one call where GoBuildWP needs a sequence of them.
• The core features are free. GoBuildWP's cache abilities all need GoBuildWP Pro.
• It runs on older stacks. WordPress 6.0 and PHP 7.4 are below what GoBuildWP supports.
• It handles WooCommerce exclusions itself, never caching logged-in customers or checkout pages, according to its listing.

GoBuildWP cannot drive xSpeed Cache

xSpeed Cache is not one of the cache layers GoBuildWP recognises, so this is not a choice of which MCP server to point at the same plugin. On a site running xSpeed, GoBuildWP's cache abilities cannot read or change xSpeed's settings, and a purge through GoBuildWP does not reach xSpeed's cache. If xSpeed installs a page-cache drop-in, wppilot/cache-check-setup reports a drop-in with no matching layer, which its own instructions describe as something caching pages that the integration does not recognise. We have not confirmed how xSpeed caches on disk.

What still works is the evidence side. cache-measure-page fetches a URL from the server and reports repeated time to first byte, whether a cache header said HIT or MISS, compression and render-blocking assets, whichever plugin produced the page. If you run xSpeed, use its own MCP server for xSpeed and treat GoBuildWP as the tool for the rest of the site.

That split has one practical consequence. When an agent edits a page through GoBuildWP on an xSpeed site, GoBuildWP's purge does not clear xSpeed's copy of that page, so check whether xSpeed purges on its own after a post update, or ask the agent to call xSpeed's purge tool before you judge the change. Otherwise you may be looking at yesterday's cached page and conclude the edit failed.

How GoBuildWP's experiment differs from optimize_site

GoBuildWP's workflow spans separate abilities so the agent can record which supported layer and setting it changed. The number of calls does not establish a speed comparison with xSpeed's untested tuning loop.

• cache-check-setup reports recognized active layers, shared settings support and available host/CDN signals; it is not exhaustive infrastructure discovery.
• cache-begin-experiment captures supported settings and returns an experiment id. Inspect captured and not_captured layers before relying on restoration.
• cache-set-settings changes one key at a time; risky keys such as js.delay, css.critical or cdn.enabled are refused without confirm=true, and each write lands in the change ledger.
• cache-purge attempts available declared WordPress-side purge callbacks and reports each outcome. cache-warm requests up to ten URLs; neither proves every provider cache is fresh.
• cache-measure-page records server-side delivery; it is not Lighthouse and cannot see LCP, CLS or INP.
• cache-verify-in-browser names what the change most likely broke and returns browser checks to run. It does not run a browser itself.
• cache-revert-experiment writes back the settings the snapshot captured for each recognised layer, purges, and reports any layer it could not restore. Layers GoBuildWP does not recognise, xSpeed among them, are not in the snapshot, a plugin that builds rewrite rules or a config file from its settings may need re-saving in its own screen, and only the five newest experiments are kept.

Deciding from the site you already have

If the site has no cache plugin yet, or you are willing to replace the one it has, xSpeed Cache gives you an engine and a self-correcting assistant loop in one install, and its free tier covers the engine. If the site already runs LiteSpeed Cache, WP Rocket, FlyingPress or another supported layer, perhaps with an asset optimiser and Redis beside it, GoBuildWP lets an agent work on that stack as it stands, across all its layers, with a snapshot to fall back to. Replacing a working cache plugin to get an MCP loop is a bigger change than most sites need, so start from the stack, not the feature list.