How to Measure Cache Hit Ratio and Diagnose Low CDN Cache Performance

Overview

A CDN cache hit occurs when an edge location can serve a request from its stored object instead of retrieving the response from the origin server. A cache miss occurs when the edge has to contact the origin, either because the object is not stored, has expired, has been purged, or is not eligible for caching.

The basic request-based cache hit ratio is:

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

For example, if a CDN records 8,500 hits and 1,500 misses for the same measurement period, the request-based ratio is 85%. The calculation is simple, but the result can be misleading if the data combines unrelated traffic. HTML pages, versioned JavaScript files, API responses, image requests, authenticated requests, and cache-bypass traffic often have very different caching behavior.

Start by defining the scope of the measurement. Record the hostname, path or asset group, HTTP method, geographic region, status-code range, and time window. Also note whether the CDN reports hits by request count, transferred bytes, or both. A byte-based ratio can better describe bandwidth savings, while a request-based ratio is often more useful for understanding how frequently the origin is being contacted.

Do not confuse CDN cache performance with browser caching. A browser may satisfy a request locally, so that request never reaches the CDN. Conversely, a CDN hit can still be slow if the client is far from the selected edge, the object is large, or the connection has other limitations. Treat browser cache, edge cache, and origin response time as separate layers.

What to track

A useful CDN monitoring view combines cache outcomes with timing, volume, and request characteristics. Track the following variables consistently so that a change can be compared with a previous period.

• Hit and miss counts: Record hits, misses, bypasses, and errors separately where the provider exposes them. A bypass is not always a normal miss; it may indicate an explicit rule, a request cookie, or a response header that prevents storage.
• Hit ratio by content type: Separate static assets, HTML documents, images, downloads, and API responses. A low ratio for private account pages may be expected, while a low ratio for hashed CSS or JavaScript files deserves investigation.
• Origin requests and origin load: Track requests reaching the origin, origin bandwidth, origin response time, and upstream error rates. A stable hit ratio with rising origin time may indicate a traffic mix or capacity problem rather than a CDN configuration problem.
• Time to first byte: Compare edge-served and origin-fetched responses. A cache hit should generally avoid an origin round trip, but TTFB is also affected by network distance, TLS setup, connection reuse, and edge selection. See the guide to improving TTFB for a broader timing checklist.
• Cache status headers: Inspect response headers such as the CDN's cache-status indicator, age information, and any diagnostic headers provided by your platform. Header names and values differ between providers, so document the meaning of each value before building a report around it.
• Cache key inputs: Note which parts of a request determine the stored object: scheme, host, path, query string, cookies, headers, and HTTP method. Small variations can create separate cache entries.
• Purges and deployments: Mark cache purges, configuration changes, releases, and content migrations on the same timeline as your metrics. A sudden drop after a purge may be normal during repopulation rather than evidence of a permanent failure.

Use command-line requests or browser developer tools to test representative URLs. Check a public asset, a cacheable HTML page, a URL with query parameters, and an authenticated or personalized route. Repeat a test after a short interval when appropriate, while remembering that different edge locations can have different cache states.

Headers are especially important when diagnosing an origin pull CDN. Review Cache-Control, Expires, Vary, Set-Cookie, and related directives. A practical policy for static assets, documents, and APIs is covered in the Cache-Control headers guide. Do not assume that a browser directive and a CDN storage rule mean exactly the same thing; confirm how your CDN interprets them.

Cadence and checkpoints

Review cache performance on a schedule rather than only when a page feels slow. A monthly review is a reasonable baseline for a stable site. A quarterly review can be sufficient for low-change websites, while sites with frequent releases, campaigns, product updates, or changing traffic patterns may need a weekly operational view and a deeper monthly review.

At each review

1. Export or record the same hit, miss, bypass, origin, and timing metrics used in the previous period.
2. Compare ratios by content category instead of relying on one site-wide number.
3. Check the top URLs and highest-origin-volume paths for unexpected query strings, cookies, redirects, or response headers.
4. Review cache purges, deployments, routing changes, DNS changes, and CDN rule edits that occurred during the period.
5. Run controlled tests from more than one network or region when regional behavior matters.
6. Record an explanation for material changes, even when the change is intentional.

Keep a small baseline table with the review date, traffic volume, request-based hit ratio, byte-based hit ratio if available, origin request count, median or percentile TTFB, error rate, and notable changes. The purpose is not to chase a universal target. It is to identify whether the CDN is handling the content it is intended to handle and whether origin load is consistent with the site's design.

How to interpret changes

A falling cache hit ratio is a signal for investigation, not a diagnosis. Work through the following sequence.

1. Confirm that the traffic mix changed

A new login flow, API feature, bot pattern, checkout route, or campaign can increase uncached requests. Compare the affected paths and methods with the previous period. A site-wide ratio may fall simply because a new category of intentionally private traffic has grown.

2. Check whether the cache key is fragmented

Query strings are a frequent source of fragmentation. Tracking parameters can cause multiple cache entries for visually identical pages if they are included in the cache key. Cookies and selected request headers can have the same effect. Normalize only inputs that are safe to ignore, and test carefully before changing the key. Removing a parameter that changes the response can serve incorrect content.

3. Inspect response headers and rules

Look for private, no-store, restrictive max-age values, or a Set-Cookie response where the route is expected to be public. Also check CDN rules that bypass caching for cookies, authorization headers, methods, file extensions, status codes, or path patterns. A rule added for one sensitive route can unintentionally cover a wider path.

4. Check purges, expiry, and deployment behavior

Frequent full-site purges can keep objects from staying warm and can create repeated origin bursts. Prefer versioned asset filenames for files that change during releases, and use targeted cache purge where practical. For HTML, choose freshness and revalidation rules that match how quickly users need updates. The edge caching and origin optimization guide provides a complementary way to connect cache behavior with TTFB.

5. Check whether the content should be cached at all

Public static assets are usually straightforward candidates for edge caching. Public HTML may also be cacheable when personalization is handled separately. Account pages, carts, checkout steps, and responses containing private data require stricter controls. For APIs, define whether responses are public, user-specific, or conditionally cacheable before setting a TTL. The API caching guide covers the edge cases that make a simple cache rule unsafe.

If the hit ratio improves but users still report slow pages, inspect edge TTFB, object size, compression, connection behavior, and origin redirects. If the ratio is stable but the origin is overloaded, verify whether the cached paths represent the requests consuming the most resources. A high ratio on small assets may not offset a small number of expensive uncached page or API requests.

When to revisit

Revisit this analysis monthly or quarterly, and immediately after changes that can alter cache behavior. Important triggers include a CDN migration, a new cache rule, a domain or DNS change, a framework or WordPress caching change, a major deployment, a new personalization feature, an API release, or a noticeable shift in origin load or TTFB.

Before each review, save a small set of repeatable test URLs and note the expected behavior for each one. For example, a versioned image should be cacheable, a public document may be cacheable under its stated policy, and an authenticated response should not be shared. Test those expectations after configuration changes instead of relying only on aggregate analytics.

Use the results to maintain three lists: content that should be cached, content that should bypass the CDN, and content whose behavior is still uncertain. Resolve the uncertain cases with header inspection and controlled tests. If the site uses WordPress or WooCommerce, review page-cache exclusions alongside CDN rules; the WordPress caching guide explains how page, object, and edge caching interact.

The goal is a predictable cache, not the highest possible percentage. Measure the right traffic, protect personalized responses, limit unnecessary cache fragmentation, and connect every ratio change to origin load and user-facing timing. That process makes cache hit ratio a practical operating metric rather than a number viewed in isolation.