Cache & optimize

The Performance group in a WordPress site’s shell holds two pages: Cache (/sites/:srv/:dom/cache) — the per-URL cache manager — and Optimize (/sites/:srv/:dom/optimize) — asset minification, compression and database cleanup. Both are WordPress-only and available on all plans. This page covers both.

Warm the cache and purge a URL, step by step

The Cache page is a searchable table of your site’s URLs (from its sitemap) with a live cache monitor on the right.

Open Cache. Each row shows a URL, its type (page/post/category/tag/author) and whether it’s currently Cached or Not cached, with the object’s age and size.
Search for a URL or use Filters to narrow by Type or Status (All / Cached / Not cached).
On a row, hit Warm to render and cache that page now, or Edge to purge it from Cloudflare. Tick several rows to purge them from the box or the edge in bulk.
Watch the Cache monitor rail: the Warm ring shows how much of your sitemap is cached, alongside on-disk object count and size.
To wipe everything, use Purge all in the monitor footer.

What else you can do

Cache page

Cache monitor rail — a live read of all four cache layers: Page cache (Nginx FastCGI — warm coverage, disk usage vs a 1 GB cap, logged-in caching), Object cache (Redis — keys, memory, DB), OPcache (PHP bytecode — memory, hit rate, cached scripts) and Edge (Cloudflare zone). Refresh metrics and Purge all live in the footer.
Cache settings drawer (the Settings button) — enable/disable the page cache, purge a single URL, warm from the sitemap with live progress, schedule an auto-refresh (daily / every N hours), toggle caching for logged-in users, and turn the Redis object cache on/off or flush it.
Reset OPcache — clears PHP’s compiled-bytecode cache. Useful after a deploy that didn’t pick up.
Edge cache — when a Cloudflare connection covers the domain, purge specific URLs from the CDN edge.

Optimize page

Performance overview — a Tuned score (how many optimizations are on), bundle count and bytes saved, plus a Measure button that snapshots live page weight (CSS/JS bytes + request count) straight from the box.
Asset optimization — a master switch, then Minify CSS (tdewolff) and Minify JS (esbuild) into pre-built static bundles, with Rebuild bundles.
CSS & JS loading — Async CSS, Critical CSS (headless-generated), Defer JS, Delay JS until interaction, Lazy-load iframes, Serve WebP images, and Minify HTML.
Remove bloat — strip Emojis, oEmbed, jQuery Migrate, XML-RPC, Pingback, RSD/WLW, Shortlink and REST-API discovery links.
Brotli compression — pre-compress text assets to .br at the Nginx vhost.
Database cleanup — Clean now (revisions, auto-drafts, trashed posts, spam comments, expired transients + OPTIMIZE TABLE) and an Auto-clean schedule (Off / Daily / Weekly).

How it works

Both pages dispatch jobs to the site’s agent, which runs everything natively — no child plugin required for the cache/optimize engine itself.

Area	Job	What the agent does
Cache status / monitor	`wp.cache` `status` / `opcache-status`	reads FastCGI cache state; probes OPcache
Warm / purge a URL	`wp.cache` `warm` / `purge-url`	renders or deletes that URL’s cache object
Purge all	`wp.cache` `purge`	clears the site’s FastCGI cache zone
URL table	`wp.cache` `urls`	lists sitemap URLs with per-URL cache state
Enable / schedule / logged-in	`wp.cache` `enable` / `cron-set` / `loggedin-set`	edits the vhost + refresh cron
Object cache	`wp.redis` `status` / `enable` / `flush`	manages the Redis object-cache plugin
OPcache reset	`wp.cache` `opcache-reset`	resets the FPM master’s bytecode cache
Optimize status / config	`wp.optimize` `status` / `set-config`	reads engine state; writes the optimization config
Build assets	`wp.optimize` `enable` / `rebuild` / `build`	minifies + bundles CSS/JS to static files
Brotli / DB clean / report	`wp.optimize` `server-tune` / `db-clean` / `report`	edits the vhost; cleans the DB; measures page weight

Page cache is Nginx FastCGI cache; warm coverage compares sitemap URLs actually cached against the total. OPcache is read by executing a PHP probe inside the site’s PHP-FPM worker — the agent prefers cgi-fcgi straight to the pool’s unix socket, bypassing Nginx/TLS/Cloudflare so the reading is accurate even on vhosts that redirect or allow-list Cloudflare IPs. Edge purge and Cloudflare zone lookup go through the control plane’s DNS integration, not the agent.

Optimize config flips are optimistic and batched — flick several switches and they save as one write; the heavy rebuild is a separate explicit action. The engine minifies into static bundles served straight by Nginx, so there’s no per-request work.

CLI & automation

Every action maps to an mz command on the box — the same engine the dashboard drives. SSH in and run them, or let an on-box AI (ClaudeCode) run them:

mz wp <domain> cache status --json               # page/object cache state
mz wp <domain> cache warm https://<domain>/path --json   # warm one URL
mz wp <domain> cache purge --json                # purge the whole page cache
mz wp <domain> optimize status --json            # optimization posture + bundles
mz wp <domain> optimize db-clean --json          # revisions/transients cleanup

Pass --json for machine output. See The mz CLI and the command catalog.

Gotchas & troubleshooting

Cached pages keep old output until purged. Optimization rewrites run at PHP render time, but the page cache stores the rendered HTML. After changing Optimize settings, Purge all on the Cache page to serve the new output.
OPcache is shared per PHP-FPM version. A Reset OPcache clears it for every site on the same PHP version on that server, not just this site. The monitor warns before you confirm.
“OPcache N/A” isn’t the same as off. If the FPM worker doesn’t respond, the monitor shows N/A and asks you to refresh, rather than falsely reporting “disabled.”
Edge purge needs a Cloudflare connection. The Edge action and zone read only appear when a Cloudflare connection covers the domain; connect it under DNS & TLS first.
Optimize needs a current agent. Older fleet agents lack the Optimize engine — the page then shows “needs a newer agent.” Update the server’s agent to enable it.
The mzpanel-agent helper installs on first enable. Turning Optimize on installs the site’s helper if it isn’t present yet.
Agent offline → read-only. Both pages need the agent online; when it’s offline the site shell shows an “agent offline” banner and the pages are unavailable.

Site overview — the health cockpit, with a Cache quick action.
The mz CLI — driving a site from the command line.
Command catalog — every mz command.