Reading the Cache Health Dashboard
The Health panel is the at-a-glance view of how your cache is doing. It shows diagnostic checks, your cache hit ratio, a 24-hour chart, and recent cache activity.
What this does
Health is a read-only status screen. It does not change any settings. It gathers four things and shows them in one place:
- Diagnostic checks — environment and cache configuration warnings.
- Cache performance — hits and misses over the last 24 hours, plus your hit ratio.
- Last 24 hours chart — an hourly breakdown of hits and misses.
- Recent activity — the newest cache events first.
The checks never write to disk and never make outbound calls, so the panel is safe to open at any time.
Why use it
When a page loads slowly or the cache does not seem to be working, this is the first screen to check. It tells you whether the cache is enabled, whether the server is serving cached files directly, and how often visitors are getting a cache hit versus a miss.
Requirements
Health is part of xSpeed Cache Free. No Pro license is needed.
Note: Some metrics, like the hit ratio and the 24-hour chart, only fill in once the cache is enabled and your site starts receiving traffic.
Where to find it
Open the xSpeed Cache dashboard and select the Health panel (the heart-pulse icon). The most important checks also appear in WordPress’s own Tools → Site Health → Status screen, so you get a heads-up even if you never open the xSpeed Cache dashboard.
The diagnostic checks
Each check shows a tone (good, warning, fail, or info), a short label, and a detail line. These are the checks xSpeed Cache runs:
| Check | What it confirms |
|---|---|
| WordPress version | You are on WordPress 6.0 or higher. |
| PHP version | Your PHP version. 8.1+ is reported as full speed; 7.4–8.0 works but is flagged as a warning; below 7.4 fails. |
| Server | Which web server xSpeed Cache detected (Apache, LiteSpeed, nginx, IIS, or Unknown) and whether GZIP can be auto-configured. |
| Cache directory writable | xSpeed Cache can write to its cache folder. If not, fix file permissions before enabling the cache. |
advanced-cache.php drop-in | The drop-in is installed and owned by xSpeed Cache. Shown only when the cache is enabled. |
WP_CACHE constant | WP_CACHE is defined and true in wp-config.php. Shown only when the cache is enabled. |
| Static-file rewrite | Whether the server is serving cache hits directly, without booting PHP. The exact check depends on your server (see below). Shown only when the cache is enabled. |
| Permalinks | Pretty permalinks are active. Page caching needs URL paths to key on, so anything other than “Plain” is fine. |
| Caching plugin conflicts | No other caching plugins are active. Running two at once causes double-caching. |
The static-rewrite check by server
This check behaves differently depending on the server xSpeed Cache detects:
- nginx — xSpeed Cache cannot write nginx config from PHP. If the check is not green, it shows a snippet to paste into your site’s
server { }block. Reload nginx after pasting so cache hits serve without running PHP. - Apache — xSpeed Cache installs a rewrite block in
.htaccess. If the block is missing, toggle Enable Cache off and on to reinstall it. If the block is present but the probe fails, confirm the block is at the top of the file and thatAllowOverrideis enabled. - LiteSpeed — cache hits are served by xSpeed Cache’s drop-in and tagged with the
X-XSpeed-Cache: HITheader. This is the expected, healthy state on LiteSpeed, not a fallback. - Other servers (IIS, Unknown) — the PHP drop-in still serves cache hits. No server-level rewrite is available.
Cache performance and the 24-hour chart
The performance numbers come from a rolling 24-hour counter. xSpeed Cache records every cache hit (a page served from cache) and every miss (a page that had to be generated), grouped into hourly buckets. The panel sums these to show:
- Hits — pages served from cache in the last 24 hours.
- Misses — pages that had to be generated in the last 24 hours.
- Hit ratio — hits divided by total requests, shown as a percentage.
The Last 24 hours chart plots these hourly buckets so you can see traffic patterns and spot times when misses spiked.
Note: xSpeed Cache counts hits from every serving path, including hits served directly by nginx or Apache below PHP. Those are folded in from the server logs the next time the dashboard loads, so very recent direct hits may appear on the following refresh rather than instantly.
A high hit ratio is the goal. A low ratio means many requests are still being generated by PHP — often because the cache was recently cleared, the cache is not enabled, or a preloader is not warming pages ahead of visitors.
Recent activity
The activity list shows recent cache events, newest first, with a timestamp and severity. Use it to see when the cache was last purged or when something went wrong.
Best practices
- Aim to clear every check of warnings before relying on the cache in production.
- Watch the hit ratio after clearing the cache. It should climb back up as pages are re-cached.
- If the static-rewrite check is not green on nginx or Apache, fix it. Server-level serving is much faster than the PHP drop-in.
Troubleshooting
The hit ratio shows 0% or looks wrong. The cache may be disabled, or the site may have had no traffic in the last 24 hours. Confirm the cache is enabled and that the diagnostic checks are green.
The WP_CACHE constant check is a warning.
The cache is configured but WordPress will not load the drop-in until WP_CACHE is set to true in wp-config.php.
The drop-in check fails. The drop-in is missing or owned by another plugin. Toggle Enable Cache off and on to reinstall it.
The Apache static-rewrite block is missing.
Toggle Enable Cache off and on to reinstall the .htaccess block.
FAQ
Does opening the Health panel slow down my site? No. The checks are read-only. The one live network probe (used to confirm static-rewrite serving) is throttled to run at most once every five minutes.
Why does LiteSpeed show the drop-in serving hits instead of a rewrite? On LiteSpeed, xSpeed Cache serves hits through its drop-in on purpose, so every hit can be tagged and counted. This is the expected behavior.
Related
- How to Enable Page Cache
- Configure Browser Cache
- GZIP Compression
- Cache Preloader