What Is a Cache Hit Ratio, and Why Does It Matter for WordPress?

Your homepage scores 95 on PageSpeed Insights. Your caching plugin is active and green across the board. Everything checks out.

And yet, if you actually looked at what’s happening in the background, you might find that a good chunk of your real visitors are hitting a page that was rebuilt from scratch, seconds before they landed on it. Not because caching is broken. Because nobody’s watching the one number that actually tells you if it’s working: your cache hit ratio.

It’s not a metric PageSpeed Insights reports. GTmetrix doesn’t show it either. But it explains more about how your site actually behaves for real visitors than either of those tools ever will.

What is a cache hit ratio, exactly?

Every time someone requests a page on your site, one of two things happens.

Either your server already has a ready-made copy of that page sitting in cache, and hands it over instantly. That’s a hit.

Or no cached copy exists yet, so your server has to build the page from scratch: query the database, run your theme’s PHP, assemble the HTML, and only then send it to the visitor. That’s a miss, and it’s the same reason a website’s first visitor almost always waits a little longer than its second.

Your cache hit ratio is simply the percentage of requests that take the fast path instead of the slow one:

Cache hit ratio = (Cache hits) ÷ (Cache hits + Cache misses) × 100

If 950 out of 1,000 page views were served straight from cache, you’re sitting at a 95% cache hit ratio. The other 5% went the long way round.

Think of it less as a performance score and more as a share of your traffic that’s actually benefiting from the caching you set up. A caching plugin that’s “on” but rarely hit is barely doing its job.

Why this matters more than your PageSpeed score

A PageSpeed Insights lab test or a GTmetrix test shows you how a specific page performed during a particular test run. A cache hit ratio answers a different question: how often requests are actually being served from cache instead of being rebuilt.

When you can measure it across real requests, your cache hit ratio tells you what proportion of traffic is actually being served from cache. Even without an aggregate percentage, checking cache status across your most important URLs can reveal whether caching is working where it matters.

A site can run a strong lab test and still have plenty of misses happening in production, if:

• Cached pages expire too quickly
• Tracking parameters create extra cache variants
• A large share of traffic is logged-in users or WooCommerce sessions that bypass cache by design

None of that shows up in a lab test. All of it shows up in your server load, your TTFB, and eventually in how visitors experience your site.

How to check your cache hit ratio on WordPress

There’s no universal WordPress “cache hit ratio” dial you can check, but there are a few reliable ways to see what’s actually happening.

Check the response headers

Open any page on your site, press F12 to open DevTools, go to the Network tab, reload the page, and click on the main document request (the first one in the list, usually your page’s URL). Look at the response headers. Most caching layers add something to tell you what happened: cache-control, age, and often a dedicated header from whatever’s doing the caching, a CDN, a caching plugin, or both. If you’re running FastPixel, the plugin adds its own header to every cached response, confirming whether that particular page was served from cache or built on the spot.

The same check works from the command line:

curl -I https://yoursite.com/some-page/

Do this across a handful of different pages and templates (homepage, a blog post, a product page, an archive), and a pattern starts to appear.

Use FastPixel’s Cache Status page

FastPixel doesn’t display a cache hit ratio percentage. Instead, its Cache Status page shows which URLs are cached and which aren’t. It won’t give you a single percentage, but it’s a quick way to check whether the pages that actually matter for your traffic are being cached. If your highest-traffic URLs are consistently showing up as uncached, that’s worth investigating.

Get an aggregate number, if you want one

If you’d rather have a hard percentage, look one layer up the stack. If you’re running Cloudflare in front of your site, its analytics dashboard reports a cache hit ratio for your zone. Your host or CDN logs may also help, if they include cache status information.

What counts as a “good” cache hit ratio?

There isn’t one percentage every WordPress site should aim for.

A mostly public blog or marketing site should naturally have a much higher hit ratio than a membership site or WooCommerce store, where logged-in sessions, carts, checkouts, and account pages need to stay dynamic.

So don’t chase 100%.

A better question is: are the pages that should be cacheable consistently being served from cache?

Your homepage, blog posts, landing pages, product pages, and category archives are usually good candidates. Carts, checkouts, dashboards, and personalized sessions often aren’t.

A miss on a page that needs to stay dynamic isn’t a performance failure. It’s the cache doing what it’s supposed to do.

Why your cache hit ratio might be lower than you think

A handful of things quietly drag this number down without ever looking like an obvious problem:

Short cache duration. If pages expire and rebuild every few minutes, you’re generating fresh misses far more often than necessary, especially on content that barely changes day to day.

Tracking parameters. Depending on how your caching layer handles query strings, URLs such as ?utm_source=newsletter can create additional cache variants or bypass caching altogether. Check how your caching setup treats common tracking parameters before assuming they’re harmless.

Logged-in visitors. WordPress serves logged-in users a different experience by design, the admin bar, personalized content, session data, so most caching setups skip the cache for them entirely. On a site with a lot of registered users or WooCommerce accounts, this alone pulls the overall number down without anything actually being wrong.

Overly broad exclusion rules. It’s tempting to exclude a page “just in case” it breaks something. Every exclusion is a page that will always miss, forever, whether or not it needed to.

Frequent purges. Clearing cached pages too often reduces how long those cached copies get a chance to do useful work. Some caching systems leave the next visitor to rebuild the page, while others warm the cache automatically. FastPixel uses automatic cache warm-up after a purge, so optimized pages can be rebuilt before a real visitor needs them.

How to improve it

• Keep cacheable pages cached for an appropriate amount of time. If content changes rarely, constantly expiring it creates unnecessary misses.
• Check how query parameters are handled. Tracking and affiliate parameters shouldn’t accidentally create unnecessary cache variants or bypass caching.
• Warm the cache after a purge. That keeps the first real visitor from doing the rebuilding work. FastPixel does this automatically.
• Review exclusions. Every URL or session excluded from page caching should have a reason.
• Use Object Cache for dynamic work. Some pages, like a WooCommerce cart or an account dashboard, were never going to be a clean page-cache hit, since their content differs per visitor. That’s where Object Cache can help: it doesn’t turn a personalized page into a cache hit, but it reduces the repeated database work underneath that dynamic request. FastPixel supports Object Cache with Redis or Memcached.

The bottom line

A good PageSpeed score tells you your site can be fast. Your cache hit ratio tells you how often visitors are actually benefiting from the caching you set up.

It’s not a metric you need to check daily. But if your site feels inconsistent, if some visitors report a snappy experience while others complain about dragging, this is usually where the answer is hiding, not in another round of image compression.

Let the right pages stay cached
FastPixel handles page caching, automatic cache warm-up, exclusions, and Object Cache, so public pages can take the fast path while dynamic content stays dynamic.

Enjoyed reading? Spread the word!