xCloud

xCloud

Detects and coordinates with xCloud's own caching layers rather than fighting them. Off by default.

Why this exists

If your host already runs a page cache and a Cloudflare layer, and a plugin also manages a page cache and a Cloudflare rule, you get results nobody can explain: purges that do nothing, stale pages that outlive every TTL you set, and two rule sets disagreeing about which paths bypass.

The integration's job is to establish who owns what and then stay out of the way.

Connect

Enter your xCloud API token (needs read:sites and write:sites) and your domain or site UUID under Integrations. Or:

define( 'GTPERF_XCLOUD_API_TOKEN', '…' );

wp gt-performance xcloud

What it reports

• Server and site identifiers, and the stack
• Whether xCloud's page cache is on, and which source serves it
• Whether xCloud's Redis is on, and whether Object Cache Pro is present
• Whether the free edge cache is on
• Whether the Cloudflare Enterprise add-on is available, plus its request counts and hit percentage

Edge ownership

When xCloud's Cloudflare Enterprise add-on is the active owner, GT Performance refuses to also manage a Cloudflare rule and reports the conflict instead of quietly creating a second one. Disable one or the other; do not run both.

This is the single most useful thing the integration does, and it is a refusal rather than a feature.

Host cache purging

Purges reach xCloud's own layers where the API allows it. Note that Cloudflare Enterprise purge is not available through the xCloud Public API token — use the Purge control in the xCloud Enterprise dashboard for that layer.

That limitation produces a specific, confusing symptom: cloudflare purge reports success, and the copy visitors receive does not change, because it is held by a layer your token cannot address. Verify a true origin render with a cache-busting query parameter rather than re-fetching the bare URL. See Troubleshooting.

Related

Cloudflare · Diagnostics · Troubleshooting