What is xSpeed Cache?

Getting Started 6 min

A caching and performance plugin for WordPress that serves saved pages straight from the web server, before PHP or the database load at all.

xSpeed Cache is a caching and performance plugin for WordPress, built by WPDeveloper. It ships in two parts: the free plugin on WordPress.org, which handles the cache and most of the optimisation work, and xSpeed Cache Pro, a separate add-on that installs beside it and unlocks further modules inside the same dashboard.

What this does

A WordPress page normally costs you a full render on every request: PHP boots, plugins load, the database is queried, the theme assembles the HTML, and only then does the visitor see anything. That work produces the same result over and over for every reader of the same page.

xSpeed does the work once, saves the finished page as a static file, and hands that file to everyone else — skipping PHP and the database entirely. That is where almost all of the speed comes from. Everything else the plugin does is the second-order work you do after the cache is in place.

How page caching works in xSpeed Cache

A visitor requests a page, and WordPress renders it as it normally would.
xSpeed saves the finished HTML to wp-content/cache/xspeed-static/{host}{request-uri}/index.html.
On the next request for that URL, a rewrite rule in your web server’s configuration matches the saved file.
The server returns it directly — before WordPress, PHP or your database load at all.

Step 3 needs server configuration, and that is the one part xSpeed can’t always do for you. On Apache it writes the rewrite into .htaccess itself when you enable page caching. On nginx the configuration lives outside WordPress, so it generates the exact block for your site and asks you to paste it in once and reload nginx.

Until that’s in place, caching still works — through the PHP drop-in. WordPress boots, but the drop-in returns the saved HTML before anything is rendered or queried. That path costs around 85 ms against roughly 5–15 ms for a static hit served by nginx, or 25–40 ms by Apache. It is the fallback on every server, and on LiteSpeed it is used deliberately: LiteSpeed can run the .htaccess rewrite, but its engine ignores mod_headers and has no per-location access log, so a static hit there would be neither labelled nor counted. The same trade applies on Apache when mod_headers isn’t loaded.

Every response carries an X-XSpeed-Cache header saying which path answered it, so you never have to guess which one you’re on — see Understanding cache HITs and MISSes.

What gets optimized

Page Cache — saves pages as static HTML and serves them without PHP. Purges itself when you publish, update a plugin or switch theme.
Minify — strips whitespace and comments from HTML, CSS and JavaScript, with optional combining, defer, delay and async loading.
GZIP Compression — shrinks every response before it’s sent. Written into .htaccess on Apache, or offered as a snippet on nginx.
Lazy Load — defers off-screen images, iframes and video until they scroll into view, keeping the first image eager so your LCP isn’t delayed.
Fonts — adds font-display: swap to Google Fonts so text never waits on a font file, and preloads the ones you mark critical.
Resource Hints — preloads the largest above-the-fold image and preconnects to font hosts so the main content paints sooner.
Browser Cache — sends Cache-Control headers (plus Expires on Apache) so returning visitors re-fetch nothing: a year for static assets, an hour for HTML.
Object Cache — configures a persistent Redis or Memcached object cache and generates the wp-config.php snippet for it.
CDN — rewrites image, font, CSS and JavaScript URLs to a pull-zone host, with a full Cloudflare zone connection and edge purging alongside it.
Database cleanup — scans and clears revisions, spam, expired transients and orphaned meta, and optimizes tables.
Disable Bloat — turns off WordPress defaults you don’t use: Dashicons on the front end, oEmbed, RSS feeds, XML-RPC, jQuery Migrate.
Heartbeat — throttles or disables the WordPress Heartbeat API per context, so an open editor tab stops polling your server.

Diagnostics sit beside all of it: a hit-ratio and health panel, a graded whole-site scan, PageSpeed Insights or GTmetrix audits with history, an activity log, and an MCP server that lets an AI agent operate the cache for you.

Why use it

Faster pages keep visitors and help your search rankings — a page that answers in 15 ms instead of a second is the difference between a reader who stays and one who leaves before anything appears.

What matters as much is that it is safe by default. Logged-in visitors are never served a cached page, and neither are admin, AJAX, cron or REST requests, so nothing personalised can leak from one reader to another. Carts, checkouts and account pages are excluded out of the box, as are the login screen, feeds and the REST API. Activating a copy you installed yourself doesn’t switch caching on at all — it prepares the ground and waits for you to decide, which means installing it changes nothing about how your site is served until you say so.

The presets are conservative in the same spirit: the wizard’s recommended profile deliberately leaves JavaScript minification and defer off, because those are the two changes most likely to break a theme.

Requirements

WordPress 6.0 or newer. Tested up to 7.1.
PHP 7.4 or newer. Works on 7.4; 8.1+ is recommended and noticeably faster.
Apache, nginx, LiteSpeed, IIS, or any standard PHP host. The static-rewrite fast path is available on Apache and nginx; every other server uses the PHP drop-in.
Pretty permalinks — anything other than Plain, since page caching keys on the request path.
A writable wp-content/cache directory.
One page cache at a time. Only one plugin can own advanced-cache.php. If another plugin’s file is already there, xSpeed asks before taking it over rather than overwriting it silently.
Multisite is supported. Each site in the network gets its own cache and its own settings.

The setup wizard checks every one of these and shows you the result before it changes anything.

Best practices

Run one page-cache plugin, not two. Only one can own the cache drop-in. A fresh install that finds another cache comes up with everything switched off rather than fighting it, and turning caching on later asks before taking over the other plugin’s file. Taking the file isn’t the same as switching that plugin off — deactivate its page cache too, because two caches running together give unpredictable results.
On WooCommerce or any store, leave the dynamic pages excluded. /cart, /checkout and /my-account are on the default exclusion list, along with the cart cookies both WooCommerce and Easy Digital Downloads set, so a shopper mid-purchase always gets a freshly built page.
Check that the static-rewrite path is actually active. Run curl -s -o /dev/null -D - https://yoursite.com/ | grep -i x-xspeed-cache logged out: HIT (nginx) or HIT (static) means the fast path is working, and HIT (php) means you’re on the fallback and there’s a server snippet worth pasting.
Test logged out, always. Your own signed-in visits are never cached, so a private window or curl is the only honest test.

Back to documentation Need more help? Contact support →