How to read your cache diagnostics
Check the plumbing caching depends on — PHP version, the drop-in, the WP_CACHE constant, directory permissions — and get the server snippet your setup is missing.
Caching depends on several things being true at once: a modern PHP, a writable directory, a drop-in in the right place, a constant defined in wp-config.php. If any one is missing, caching quietly does less than you think. The Overview tab checks each and tells you which is wrong.
Where to find it
- In your WordPress admin, click xSpeed Cache in the left menu.
- In the xSpeed Cache sidebar, open the Health & insights group.
- Click the Health card — Overview is the default tab.
Shortcut: open
wp-admin/admin.php?page=xspeed#/insights/healthdirectly.✅ This tab is part of xSpeed Cache (Free).
- Hit ratio · 24h — with a sparkline of recent history.
💡 This counts requests that reached your server. If a CDN or Cloudflare sits in front, edge-served requests never arrive here and aren’t counted — which is why this figure can differ from your analytics, and why it is described as origin-layer only.
Settings at a glance
This tab has no settings — it’s a read-only diagnostic report:
| Element | What it shows |
|---|---|
| Hit ratio · 24h | Percentage served from cache, with hit and miss counts. |
| Diagnostics list | Pass/warn status for each caching prerequisite. |
| Recommendations | ⭐ Pro — ranked, rule-based suggestions with an Apply button. |
| Server config snippet | The nginx or Apache config your setup needs. |
How it works
Every item is checked live when the panel loads — nothing here is cached or remembered from a previous visit. A coloured dot marks each: green for satisfied, amber for something needing attention, grey for informational.
The hit ratio at the top is drawn from the same 24-hour counters that Page Cache reports and Adaptive Cache profiles, so all three agree.
Recommendations
- Suggestion count — with Re-scan to re-evaluate.
- Individual suggestions — each with a severity and an action.
⭐ Recommendations is part of xSpeed Pro. Without a licence this card shows a locked preview; everything else on this tab is Free.
A rule-based engine audits your current settings plus your server state and surfaces the changes most likely to improve things. Each carries a severity — Medium, Low — and most have an Apply button that makes the change for you.
Some are marked Manual instead. Those need something xSpeed can’t do from WordPress — installing Redis, for instance, is a server task, so the panel explains it rather than offering a button.
This is the most useful thing on the tab for most people. Rather than reading every panel and deciding what matters, you get a short ranked list derived from your actual configuration.
💡 Re-scan after making changes. The suggestions reflect state at scan time, so a recommendation you’ve already acted on will linger until you re-scan.
💡 It only appears on this tab. The summary bar above the tab strip follows you to Visitors and PageSpeed; the recommendations do not — switch tabs and they’re gone until you come back here.
The diagnostics list
- Diagnostics — each prerequisite with its current status.
| Check | What it means |
|---|---|
| WordPress version | Meets the 6.0+ minimum xSpeed requires. |
| PHP version | Modern PHP runs meaningfully faster. |
| Server | Which server was detected — this determines what xSpeed can configure automatically. |
| Cache directory writable | Without write access, nothing can be cached at all. |
| advanced-cache.php drop-in | The file that serves cached pages before WordPress loads. |
| WP_CACHE constant | Must be defined and truthy in wp-config.php, or the drop-in is never used. |
| Static-file rewrite | Whether your server routes directly to cached files, skipping PHP. |
The last three are the ones worth understanding, because they form a chain.
The drop-in and the constant work as a pair. advanced-cache.php is what serves a cached page before WordPress fully loads — but WordPress only looks for it when WP_CACHE is true. Either one missing and page caching silently doesn’t happen, even with everything switched on in the settings.
Static-file rewrite is the optional last step. By default the drop-in serves cached HTML through PHP, which is already fast. With a server rewrite, your server finds the cached file itself and never invokes PHP — faster still. On nginx that requires pasting config manually, so this check often shows amber even on a correctly configured site. Amber here means “there’s more available”, not “something is broken”.
The server config snippet
- Server config — the unified snippet for your server, with Copy.
When your server needs manual configuration, the full snippet appears here with a copy button. It’s unified — one block covering static-file rewrites, compression directives, and cache headers together, rather than separate snippets per feature.
That matters for a practical reason. Several panels (GZIP, Browser Cache, Page Cache) each need nginx directives, and this is where they’re gathered. You paste once rather than hunting through panels.
⚠️ Re-copy the snippet after toggling features. The block is generated from your current settings, so enabling something that needs a directive changes it. The panel says as much — re-copy after toggling features, and reload nginx afterwards.