Cache hit ratio: what it measures per CDN

Why the same name gives different numbers

A hit ratio is the number of requests (or bytes) served from cache, divided by something. The something is what differs. It can be every request, only the requests that could have been cached, or hits plus misses. Requests that bypass the cache, requests that fail, and requests that need a check with the origin can each be in or out. A vendor page that does not say which is leaving the reader to guess.

For the status words these definitions rest on, see cache hit and miss and how to read Age, Cache-Control and X-Cache.

What each CDN's documentation says

Amazon CloudFront

CloudFront's monitoring page lists a metric called Cache hit rate among the additional metrics, which must be turned on for each distribution and carry an additional cost. It defines the metric as "the percentage of all cacheable requests for which CloudFront served the content from its cache", and adds that "HTTP POST and PUT requests, and errors, are not considered cacheable requests."

A separate CloudFront guide to improving the ratio words it more loosely, as the proportion of viewer requests that are served directly from the CloudFront cache instead of going to the origin servers. The metric page is the definition of the metric. The guide is a plain-language description.

Unit: requests. Denominator: cacheable requests, with POST, PUT and errors stated as outside it.

Fastly

Fastly's historical stats reference describes the hit_ratio field in one line: "Ratio of cache hits to cache misses (between 0 and 1)." The same page lists related fields separately: hits ("Number of cache hits"), miss ("Number of cache misses"), errors ("Number of cache errors") and pass ("Number of requests that passed through the CDN without being cached").

The page does not say whether passes or errors are part of the ratio, and it does not say whether the unit is requests or bytes. Treat any formula you write for it as your own inference rather than Fastly's.

Google Cloud CDN

Google's Cloud CDN logging page lists Cache hit ratio as a core metric on the predefined dashboards, and defines it as "the ratio, as a percentage, of requests served directly from the Cloud CDN cache versus the total number of requests."

The page lists the log fields cacheHit and cacheLookup and uses them in filters, but does not define them in the way a formula would need. It does not say what the "total number of requests" contains. Cloud CDN exports monitoring data to Cloud Monitoring, and the metric list there was not verified for this article.

Unit: requests. Denominator: the total number of requests, as the page words it.

Azure Front Door

Azure Front Door (Standard and Premium tiers) documents a metric called Byte Hit Ratio rather than a request-based one. Microsoft describes it as "the percentage of traffic that was served from the Azure Front Door cache, computed against the total egress traffic", and gives the formula as (egress from edge - egress from origin) / egress from edge.

• The page states two cases that are left out of the calculation: caching explicitly disabled through the Rules Engine or query string caching behavior, and a Cache-Control directive of no-store or private.
• The metrics reference lists no ratio metric for the classic tier.
• Per-request logs carry a Cache Status field. Microsoft documents HIT and REMOTE_HIT as served from the cache, MISS as served from the origin, and PARTIAL_HIT as a response where some bytes came from the edge cache and others from the origin. The pages read do not turn these into a request-based ratio.

Unit: bytes. Denominator: total egress from the edge, with the exclusions above.

Cloudflare

Cloudflare's cache analytics page splits traffic into Served by Cloudflare and Served by Origin. Served by Cloudflare "indicates content served by Cloudflare that did not require contacting your origin web server." The page has two views. Requests is the default and Data Transfer is described as useful for cost analysis.

• Revalidated requests are counted differently by view. In Data Transfer they count as Served by Cloudflare, because the response body is served from cache. In Requests they count as Served by Origin, because Cloudflare still contacts the origin.
• The page says the Requests summary is "based on a sample of requests, not the full dataset", with totals extrapolated from the sample. It does not say whether the Data Transfer view is sampled.
• The page gives no formula and does not mention DYNAMIC or BYPASS, so it does not say whether those requests are in the totals. For what those statuses mean, see the Cloudflare cache responses page.

Unit: requests or bytes, depending on the view. Denominator: not stated as a formula.

The definitions side by side

How the definition moves the number

The counts below are invented to show the arithmetic. They are not from a real site and they are not any vendor's formula. Suppose a CDN received 1,000 requests: 700 were served from cache, 100 went to the origin as misses, and 200 could not be cached at all.

Same traffic, two different numbers. A third number is possible if the unit is bytes rather than requests, because the hits and the misses may be different sizes. None of these is wrong. They answer different questions, which is why a ratio only means something next to its definition.

Before you compare two ratios

• Check the unit. A request-based ratio and a byte-based ratio can differ on the same traffic.
• Check the denominator. Find out whether uncacheable, bypassed, failed and revalidated requests are in it.
• Check whether the figure is sampled or complete, and over which time window.
• Compare a ratio only with another from the same CDN and the same definition. Across CDNs, compare the definitions first.

What a ratio does not tell you

A ratio is an aggregate. It does not say which URLs missed, and a single page that never caches can sit inside a ratio that looks fine. For a single page, the response headers from one request show what the cache did with it. For a CDN's own wording on which responses are cacheable, read its caching documentation.

Where sitewarm fits

sitewarm requests pages from your sitemap, up to the scan's URL limit, and reports the cache state the CDN returns for each one, with the vantage point it was measured from.