Our HTTP server measures itself continuously, and we can share those measurements for your site. This article explains what we track, what the numbers mean, and — importantly — which “misses” are working as intended rather than something to fix.

For how your site is actually served, see WeynWebWorks HTTP-Server.

The two cache layers

A page request can be answered from three places, tried in this order:

1. Memory cache — the page is held in the server’s RAM and returned immediately. Fastest, but bounded: all sites on a server share one memory budget, and the least recently used pages are dropped to make room.
2. Disk cache — the page was already written to disk by WP Rocket, and we serve that file directly. Slightly slower than memory, but effectively unlimited in size, and still completely skips PHP and your database.
3. PHP — WordPress renders the page from scratch. This is the expensive path we are trying to avoid.

You can see which one answered any request using the X-Cache response header: HIT means it came from a cache, MISS means PHP rendered it. When it came from the disk layer we also send X-Cache-Source: wp-rocket-disk.

What we measure, per site

• Hits — requests answered from cache without starting PHP.
• Misses — the page was cacheable, but no cached copy existed yet, so PHP rendered it. The next visitor may get a hit.
• Bypasses — the request was never eligible for caching in the first place, with a recorded reason (see below).

The figure worth watching is the share of cacheable requests that hit: hits ÷ (hits + misses). A low number usually means the cache has not been warmed for your most-visited pages yet, not that caching is broken.

Why “bypassed” is often correct

Most bypasses are the cache protecting your visitors, and raising the hit rate by removing them would be a bug, not an improvement. The common reasons:

• Logged in, or has a cart — anyone with a WordPress login, a WooCommerce cart, or a pending comment always gets a freshly rendered page. Serving them a cached copy would show them someone else’s view of the site.
• Form submissions — anything that is not a normal page view (a POST) is never cached.
• Search results and filtered URLs — pages with a query in the address are usually unique per visitor, so they are not cached by default. Marketing parameters such as utm_source are the exception: those are stripped first, so a campaign link still gets a cached page.
• Feeds, embeds and the REST API — excluded deliberately, because they are not ordinary pages.
• Mobile visitors on a site with a separate mobile cache — if your site keeps distinct mobile pages and the mobile version of a page has not been generated yet, we render it with PHP rather than risk sending the desktop layout to a phone. This is intentional and we do not “optimise” it away.
• Link preview bots — services such as WhatsApp and Facebook preview fetches are excluded, so their requests never populate or consume your cache.

Scheduled tasks (WP-Cron)

WordPress runs scheduled work — publishing posts, sending queued mail, plugin maintenance — through a mechanism called WP Cron. By default it piggybacks on visitor requests, which means it competes with real visitors for server capacity and runs unpredictably on a quiet site.

We can instead run it on a fixed schedule from the server itself, outside the web request path. When that is enabled for your site we record, per site:

• When scheduled tasks last completed successfully — the single most useful number, because it tells you at a glance whether maintenance is actually happening.
• How long each run takes, and how often runs are deferred because the server was briefly busy. Deferrals are normal and self-correcting: scheduled work yields to real visitors.

If you rely on scheduled work — order mails, feed imports, timed publishing — this is the measurement to ask us about. We alert on it, so a site whose scheduled tasks stop running is flagged rather than discovered weeks later.

Asking for your numbers

All of the above is recorded per site and kept for long-term comparison, so we can answer questions like “did caching improve after that change?” or “is anything scheduled failing on my site?”. Contact us and we will pull the figures for your domain — and if the numbers point at something worth tuning, we will tell you what and why.