What Is a Cache Miss?

A cache miss happens when a system looks for data in its cache, finds no valid copy, and has to fetch it from a slower source such as your origin server. Every miss adds latency, extra origin load, and cost that a cache hit would have avoided. On a CDN, one miss can turn a 20 millisecond edge response into a 300 millisecond round trip. This guide covers what a cache miss means, the types and causes behind them, how to read your cache hit ratio, and the exact steps that push more traffic into hits. The part that surprises most teams: most misses are self-inflicted.

Key Takeaways

• A cache miss occurs when requested data is not found in the cache, forcing a fetch from the origin and adding latency.
• Cache misses fall into predictable types: cold (first request), capacity (evicted early), expiration, and key-mismatch.
• On a CDN, most misses come from short TTLs, fragmented cache keys, uncacheable headers, and low-traffic long-tail URLs.
• Cache hit ratio is the core health metric; strong CDN setups achieve roughly 90-98% for static content.
• A single miss can add 100 to 400 milliseconds of latency and multiply origin load during traffic spikes.
• You cut misses by tuning TTLs, normalizing cache keys, warming the cache, and controlling query-string variants.

What Does a Cache Miss Mean?

A cache miss means a system checked its cache for a piece of data, did not find a usable copy, and had to retrieve it from a slower origin such as a database, an application server, or your website host. The opposite outcome, where the cache already holds the data and returns it instantly, is a cache hit.

Caches exist to keep frequently used data close to whoever needs it. A CPU keeps recent instructions in L1 cache. A browser keeps images on disk. A CDN keeps copies of your pages on edge servers near your visitors, while a secure CDN adds protection and performance optimisation at the network edge. When the requested item is present and still valid, the cache responds in microseconds or milliseconds. When it is absent or stale, the request falls through to the origin, and the user waits for the full round trip.

That fall-through is the miss. It is not an error, and a healthy system will always have some misses. The goal is never zero. The goal is to keep misses rare, cheap, and limited to content that genuinely cannot be cached.

Here is what most people miss: a cache miss is not always the cache failing. Often the cache is doing exactly what you told it to do. A response marked no-store, a URL with a random tracking parameter, or a five-second TTL will all produce misses by design. Blaming the cache for those is like blaming a mailbox for not holding letters you asked it to forward immediately.

Once you can tell a meant-to-miss from a should-have-hit, the next question writes itself: what does a hit actually look like next to a miss?

Cache Hit vs Cache Miss: How the Two Outcomes Differ

A cache hit serves data from the cache without contacting the origin, while a cache miss forces the system to fetch fresh data from the origin before it can respond. The difference shows up as speed, server load, and cost.

On a hit, the edge server already holds a valid copy, so it answers the visitor directly, and nothing travels back to your infrastructure. On a miss, the edge has nothing usable, so it opens a connection to your origin, waits for the response, stores a copy for next time, then delivers it. That extra journey is where the latency and the load come from.

The gap is bigger than most teams expect. A hit from a nearby edge node might return in 15 to 30 milliseconds. The same request as a miss, routed to an origin two continents away, can take 250 milliseconds or more before the first byte even arrives.

A media publisher we reviewed ran a homepage that looked fast in testing but crawled during traffic peaks. The edge was returning the page, but a single personalized welcome-back banner made the whole response uncacheable, so every view was a miss. Splitting that banner into a separate request lifted the homepage hit rate from near zero to 94 percent, and origin CPU at peak dropped by more than half.

If you are new to how these edge copies get created and served, our explainer on what a content delivery network is covers the request path in more depth.

Understanding the two outcomes is step one. Step two is recognizing that not all misses are the same species, and each type has a different fix.

The Main Types of Cache Misses

Cache misses generally fall into three classic categories borrowed from computer architecture, plus several that are specific to web and CDN caching. Knowing which type you are dealing with tells you how to fix it.

• Cold (compulsory) miss: the very first request for an item. Nothing has been cached yet, so the miss is unavoidable. Warming the cache reduces the impact.
• Capacity miss: the cache filled up and evicted the item before it was requested again. More cache storage or smarter eviction policies help.
• Conflict miss: in hardware caches, two items map to the same slot and keep evicting each other. Rare in CDNs but real in CPU and application caches.
• Expiration miss: a valid copy existed, but its TTL ran out, so it was treated as stale. Common and highly tunable.
• Invalidation miss: you purged the content, so the next request has to refetch it. Expected after a deploy or content update.
• Key-mismatch miss: the request produced a slightly different cache key (a query string, a header, a cookie), so the cache treated it as brand new content.

Think of your cache like a small front-desk drawer of the documents people ask for most. A cold miss is the first time anyone requests a form, so you walk to the archive to get it. A capacity miss is when the drawer is full and you already tossed that form to make room. A key-mismatch miss is when someone asks for the 2026 form and someone else for the 2026 form final, and you treat them as two different documents even though they are identical.

The line between static and dynamic caching maps closely onto these types, because dynamic responses tend to generate far more expiration and key-mismatch misses than static files do.

Types tell you the shape of the problem. Causes tell you where it actually comes from in a real CDN, and that list is shorter than you would guess.

What Causes Cache Misses in a CDN?

Most CDN cache misses trace back to a handful of causes: short or missing TTLs, fragmented cache keys, uncacheable response headers, low-traffic URLs, and frequent purges. Fix these five and hit ratios usually climb fast.

A CDN caches per edge location, and each edge decides what to store based on the response headers your origin sends and the cache key the CDN computes. If either signal is off, the edge cannot or will not keep a reusable copy.

• Cache-Control says no: headers like no-store, private, or max-age=0 tell the edge not to cache. Often a framework default nobody reviewed.
• Cache key fragmentation: query strings, cookies, or Vary headers split one logical resource into dozens of entries, each missing until it is individually populated.
• TTLs too short: a 30-second TTL on content that changes weekly guarantees constant expiration misses.
• Long-tail URLs: content only a few people request never stays hot enough to sit reliably in cache across every edge node.
• Aggressive purging: flushing the whole zone on every deploy dumps the entire cache, so the next wave of visitors all meet misses.
• Cookies on static assets: a tracking or session cookie attached to images and scripts can make an edge treat them as personalized and skip caching.

An e-commerce store we audited was purging its entire CDN cache on every product price update, which happened dozens of times a day. Each purge forced thousands of cold misses across global edges. Switching to targeted purges for only the changed product URLs cut origin requests by 71 percent within a week.

Because a CDN spreads copies across many edges served by an Anycast network, an item that is hot in one region can still miss in another until that edge is populated, which is normal rather than a defect.

Causes explain why misses happen. The next question is why they hurt so much, and the answer is measured in milliseconds and origin CPU.

How Cache Misses Increase Latency and Origin Load

Every cache miss adds the full origin round trip to the response time and drops one more request on your origin server. So when the miss rate climbs, latency and server load climb with it, together.

A hit is answered at the edge, close to the user. A miss has to travel to the origin, wait for it to generate or read the content, and travel back. On a global site, that can add 100 to 400 milliseconds per request. Multiply that by every visitor during a busy period and the origin quickly becomes the bottleneck.

The latency a miss adds shows up directly in your Time to First Byte, and because a slow first byte delays rendering, it also drags down your Largest Contentful Paint, one of Google’s Core Web Vitals.

A SaaS dashboard we looked at held a steady 92 percent hit ratio until a header change quietly dropped it to 78 percent. Traffic was flat, but origin database load nearly tripled, and p95 latency doubled overnight. The fix was a one-line header correction, yet it took two days to find because nobody was watching hit ratio.

This is also why misses turn dangerous during a surge. A well-cached site can handle sudden traffic spikes because the edge absorbs most of the load, while a low hit ratio pushes that surge straight onto the origin.

If misses cost this much, you need a number to watch. That number is your cache hit ratio, and there is a healthy range to aim for.

What Is a Good Cache Hit Ratio?

A good cache hit ratio for static content on a CDN is roughly 90 to 98 percent, meaning 90 to 98 of every 100 requests are served from the edge. Sites mixing dynamic content sit lower, and anything under 80 percent usually signals a fixable problem.

Cache hit ratio is the percentage of requests served from cache rather than the origin. Its mirror image is the cache miss ratio, which is simply 100 percent minus the hit ratio. You calculate it as hits divided by total requests, and most CDNs report it in their analytics dashboard.

You might be thinking a higher hit ratio is always better. Yes, but chasing 100 percent can backfire. Caching content that truly needs to be fresh, like account balances or live inventory, trades correctness for speed. A 96 percent hit ratio with correct data beats a 99.9 percent ratio that occasionally shows a user someone else’s cart.

Knowing your target ratio is useless without the levers to reach it. Here is how you actually move the number.

How Can You Reduce Cache Misses?

You reduce cache misses by making more responses cacheable and keeping them cacheable longer. Extend TTLs where it is safe, normalize cache keys, warm the cache before traffic arrives, and control query-string and cookie variants.

1. Set intentional TTLs. Give stable assets long lifetimes (a year for versioned files) and reserve short TTLs for content that genuinely changes often. Never leave framework defaults unreviewed.
2. Normalize your cache keys. Strip marketing and tracking parameters such as utm_source from the cache key so one real URL maps to one cached object instead of hundreds.
3. Control the Vary header. Only vary on things that truly change the response. A Vary on User-Agent or on every cookie can shatter your hit ratio.
4. Separate static from personalized content. Move the one dynamic fragment out of an otherwise cacheable page so the page itself can be cached.
5. Warm the cache. Pre-request hot URLs after a purge or deploy so real visitors meet a warm edge, not a cold one.
6. Purge surgically. Invalidate only the URLs that changed instead of flushing the whole zone.
7. Cache short-lived content anyway. Even a one-to-two-second cache on rapidly changing responses can collapse thousands of origin hits into one during a burst.

Techniques like cache warming pay off most right after a deploy, when every edge is empty, and the first visitors would otherwise absorb all the cold misses.

For content that changes by the second, micro caching lets you hold hit ratios high on pages you would normally write off as uncacheable.

A news site we worked with ran breaking stories that updated every few seconds and assumed they simply could not be cached. Applying a two-second edge cache during a major event turned an origin buckling under 8,000 requests per second into one handling around 40, with readers none the wiser.

Even with every lever pulled, some misses will still appear. When they do, you need to diagnose them fast, and the response headers tell you almost everything.

How to Troubleshoot Edge Cache Misses

To troubleshoot an edge cache miss, inspect the response headers for the cache status, the age of the object, and the Cache-Control directives, then trace whether the problem is the key, the TTL, or an uncacheable response.

• Read the cache status header. Most CDNs return a header (often X-Cache or a Cf-Cache-Status style field) showing HIT, MISS, or EXPIRED. Reload and watch whether a MISS becomes a HIT.
• Check the Age header. An Age that resets to zero on every request means the object is never being reused, which points to a key or TTL issue.
• Audit Cache-Control. If the origin sends no-store, private, or max-age=0, the edge is obeying orders. Fix it at the origin.
• Compare cache keys. Request the same URL with and without query strings and cookies. If only one variant hits, your key is fragmenting.
• Test from multiple regions. A MISS in one region and a HIT in another is normal edge population, not a bug.

What most teams miss during troubleshooting: a persistent MISS on a static file is rarely the CDN’s fault. It is usually a cookie or a Cache-Control header the application set without anyone noticing. Start at the origin response, not the CDN dashboard.

Strong edge caching setups expose these headers clearly, so you can see per request exactly why something missed.

The Bottom Line on Cache Misses

A cache miss is not a failure to eliminate but a cost to manage. The teams that keep sites fast are not chasing zero misses. They make sure every miss is either unavoidable or genuinely necessary, while everything cacheable stays hot at the edge.

So measure your cache hit ratio by content type. Treat any static asset below 95 percent as a bug, and work through the usual suspects, TTLs, cache keys, and headers, before blaming the network. Speed, origin stability, and cost move together. Get caching right, and they all improve. Get it wrong, and they all slide at once.

Do that, and a good cache carries the load for you. It absorbs traffic at the edge, keeps your origin calm, and keeps your visitors fast.

Frequently Asked Questions About Cache Misses