CDN Cache Hit Ratio: Why Your CDN Is Not Making You Faster

Short answer: The cache hit ratio is the share of requests your CDN answers from its own cache instead of fetching them from your server. A low ratio means most visitors still wait for your origin server, so the CDN adds little speed. Check the cache status headers on your pages, cache HTML where it is safe, remove cookies and needless query strings from cacheable responses, set clear Cache-Control headers and avoid purging the whole cache after every small change.

What cache hit ratio means

A content delivery network (CDN) keeps copies of your files in data centres close to visitors. When a request arrives, the CDN either has a fresh copy and serves it immediately, which is a hit, or it does not and forwards the request to your server, which is a miss. The cache hit ratio is simply:

hits ÷ (hits + misses)

A hit is usually answered in tens of milliseconds from a nearby location. A miss adds the full round trip to your server, the time your server needs to build the page, and the transfer back through the CDN. On a miss, the visitor can even be slightly slower than without a CDN, because there is an extra hop.

Many site owners switch on a CDN, see the dashboard say “active” and assume the site is now fast. Whether it actually is depends on the hit ratio for the requests that matter most, especially the HTML of your pages. If you are still deciding whether you need a CDN at all, start with our plain-language CDN guide.

Two ratios: by requests and by bandwidth

CDN dashboards often show the hit ratio in two ways, and they tell different stories:

• By requests. The share of individual requests served from cache. This reflects how often visitors avoid a trip to your server.
• By bandwidth. The share of bytes served from cache. Large images and videos dominate this figure, so it can look excellent even when every HTML page is a miss.

For perceived speed, the most important single request is the HTML document, because the browser cannot start loading anything else until it arrives. A site where all images are cached but every page is a miss still has a slow first byte. That is why you should look at the cache status of the HTML itself, not just the overall percentage.

How to check whether a page is served from cache

You do not need dashboard access to see the cache status. Every CDN adds response headers that reveal it:

1. Open the page in your browser, open developer tools and go to the Network tab.
2. Reload the page, click the first request (the HTML document) and look at the response headers.
3. Find the cache status header. Names vary by provider: CF-Cache-Status, X-Cache, X-Cache-Status or similar.
4. Reload two or three times. The first request may be a MISS; repeated requests from the same region should become HIT.
5. Check the Age header too: a value above zero means the response came from a cache and shows how many seconds old the copy is.

Typical values and what they mean:

Why the hit ratio is low: the usual causes

• HTML is not cached at all. Many CDNs cache only static files such as images, CSS and JavaScript by default. HTML pages pass straight through unless you add a rule, so the slowest part of the page gains nothing.
• Cookies on every response. A Set-Cookie header usually makes a response uncacheable. Analytics, consent tools, sessions or a plugin that starts a session on every page can quietly disable caching site-wide.
• Restrictive Cache-Control headers. no-cache, no-store, private or max-age=0 sent by the server tell the CDN not to store or reuse the response. Our guide to Cache-Control headers explains each directive.
• Query strings create endless variants. Tracking parameters such as utm_source or ad click IDs turn one page into thousands of cache keys, each starting with a miss.
• A broad Vary header. Vary: User-Agent or Vary: Cookie splits the cache into many small pieces that rarely get reused.
• Short cache lifetimes. A lifetime of a few seconds or minutes forces frequent trips to the origin, even for content that changes once a week.
• Frequent full purges. Clearing the entire cache after every edit throws away all hits and sends the next wave of visitors to your server.
• Low traffic per location. Edge caches evict files that are rarely requested. A small site with visitors spread worldwide will always have more misses than a busy one.

How to raise the hit ratio safely

1. Cache HTML for anonymous visitors. Add a rule to cache pages for visitors who are not logged in and have no cart, and bypass the cache for admin areas, account pages, checkout and carts. This is the change with the biggest effect on most sites.
2. Stop unnecessary cookies. Make sure public pages do not set session cookies. Many analytics and consent cookies are set by JavaScript in the browser and do not affect the CDN; the problem is cookies set by the server on every response.
3. Set explicit lifetimes. Give versioned static files a long lifetime, for example a year with fingerprinted file names, and give HTML a shorter edge lifetime with s-maxage while browsers keep a short max-age.
4. Normalise query strings. Configure the CDN to ignore marketing parameters in the cache key, or sort and strip them. Pages should not be cached separately for every campaign link.
5. Narrow the Vary header. Keep Vary: Accept-Encoding and remove variants your site does not need.
6. Purge precisely. Purge only the URLs you changed, or use your CMS’s CDN integration to do it automatically, instead of clearing everything.
7. Use an origin shield or tiered cache if offered. These features let edge locations fetch from an intermediate cache instead of your server, which raises the effective hit ratio for sites with global traffic.

Caching HTML at the edge works best on top of good page caching on your own server, so misses are still fast. Our article on page caching explains how the two layers fit together.

What not to cache

Raising the hit ratio must never mean showing one visitor’s data to another. Exclude these from shared caches:

• logged-in pages, account dashboards and admin areas;
• cart, checkout and order confirmation pages;
• pages with personal greetings or prices that depend on the user;
• form endpoints, search results with personal filters and API responses with user data.

Test carefully after adding an HTML cache rule: log in, add products to a cart and check in a private window that nothing personal appears for anonymous visitors.

Measuring the effect

After changes, compare before and after with the same measurements. Watch the HTML request’s cache status and time to first byte from a few locations, the hit ratio by requests in the CDN dashboard, and the server response time reported in speed tests. If the CDN works, server load usually falls as well. For deeper diagnosis of a slow first byte, see how to reduce server response time.

How Site AI Audit helps

Site AI Audit measures the signs that tell you whether caching works: server response time, compression and page weight, plus Google PageSpeed and Core Web Vitals on mobile. When the server answers slowly despite a CDN, that shows up as a ranked finding with a plain-language fix. You can run a free check, and paid plans add re-checks after each change and weekly monitoring, as shown on the pricing page.

Related reading

• Image CDNs Explained: Automatic Resizing and Modern Formats
• Does Server Location Affect Website Speed? What to Know
• CDN SSL Modes Explained: Flexible vs Full vs Full (Strict)

The bottom line

A CDN only makes your site faster when it answers from cache. Check the cache status of your HTML, not just images, and look at why requests miss: uncached HTML, server cookies, restrictive headers, query string variants or constant purging. Fix those, keep personal pages out of the cache, and the CDN starts doing the job you are paying it for.

FAQ

What is a good CDN cache hit ratio?

There is no universal target, because it depends on traffic, content and how much of the site is personal. Static files should be served from cache almost always. For HTML, the aim is that public pages are usually hits for repeat visitors in the same region.

Why does my CDN show MISS on every reload?

The response is probably not cacheable: the HTML may not be covered by a cache rule, the server may send a cookie or a no-cache header, or a query string or Vary header may create a new variant each time. Check the response headers to find which one applies.

Is it safe to cache HTML pages on a CDN?

Yes for public pages that look the same for every anonymous visitor. Exclude logged-in areas, carts, checkout and anything personal, and test with a private browser window after enabling the rule.

Does a low hit ratio slow my site down?

It means the CDN brings little benefit, and misses can be slightly slower than going direct because of the extra hop. The site is then only as fast as your origin server, so slow hosting shows through.

Should I purge the CDN cache after every change?

Purge only the URLs that changed. Clearing the whole cache sends every following visitor to your server until the cache refills, which temporarily removes the CDN’s benefit.