Tiered caching: the checkbox that cuts origin load and almost nobody checks

Pablo Camino, Founder of Plimie · October 16, 2026

When we think about a CDN, we usually picture one layer: lots of edge locations close to users, and an origin somewhere behind them. A request comes in, the nearest edge checks its cache, and on a miss it goes to the origin.

That model has a cost that’s easy to overlook. Every edge location has its own cache. If you have content that’s requested from many places, each location misses independently and each one asks your origin for the same object. The more global your audience, the more your origin pays for it.

Tiered caching is the fix for this, and on many plans it’s a setting rather than a project. It’s also one of the settings that nobody revisits after the initial setup. In this post we’ll explain what it does, when it helps and when it doesn’t, and how to check whether it’s actually enabled for your traffic.

Imagine an image on your homepage. It’s cached with a one-day lifetime. Users around the world load the page, and each edge location that serves them has to fetch the image once per day.

If your traffic is served by dozens of edge locations, that’s dozens of origin fetches per object per cache lifetime. Multiply that by every asset, every page, and every purge, and a large share of your origin traffic turns out to be the same content requested again by different parts of the same CDN.

It gets worse right after a deploy or a cache purge. Every location goes cold at once, and they all ask the origin at the same time. That spike is often what actually sizes your origin infrastructure.

Tiered caching adds a layer between the edge and your origin. Instead of each edge location going straight to the origin on a miss, it first asks an upper-tier cache. Only if the upper tier also misses does the request reach your origin.

Without tiers: edge (miss) ---------------------------> origin

With tiers: edge (miss) --> upper tier (hit) [origin not contacted] edge (miss) --> upper tier (miss) -----> origin

The upper tier is shared by many edge locations. Once it has an object, every edge behind it can fill from there. The result is that your origin sees roughly one fetch per object per upper tier, instead of one per edge location.

Different providers call this different things: tiered caching, an origin shield, a regional or mid-tier cache. The details vary, but the idea is the same.

When the conditions above apply, the difference looks like this. Without tiers (left), every edge location is its own client of your origin. With them (right), your origin sees a handful of well-behaved clients that each ask once. The next step is confirming which side of this picture you are on.

This takes a few minutes and read-only access.

Find the tiered caching (or origin shield) setting for each property and note whether it’s enabled and which topology it uses. Check every property that serves real traffic, not just the main one. It’s common for one property to have been configured carefully and the rest left at their defaults.

If tiers are working, your origin should receive noticeably fewer requests than the total number of edge cache misses. Pull both numbers for the same time window:

edge cache misses (all locations): A requests received at origin via CDN: B

If B is close to A, either tiering is off or the misses are for content that isn’t cacheable.

Many CDNs expose cache status in response headers, and some indicate whether a response was served by an upper tier. Request the same object from a couple of different locations (for example, through a VPN or a remote machine) after a purge:

curl -sI "https://www.example.com/static/hero.jpg" | grep -iE "cache|age|via"

If the second location gets a response with a non-zero Age even though it was its first request, it likely filled from an upper tier rather than from your origin.

The cleanest test is to watch origin traffic right after a deploy or purge. With tiering, the spike should be smaller and shorter, because a limited number of upper-tier caches refill instead of every edge location at once.

Tiered caching is usually low-risk, but it’s still a change to how traffic reaches your origin:

Tiered caching is one of the rare settings where a single change can meaningfully reduce origin load without touching application code. It’s also easy to forget, because nothing breaks when it’s off. Your origin just works harder than it needs to.

At Plimie we’re building read-only reviews that check whether features like this are actually enabled and doing their job across all of your properties. Our pilot is free and invite-only, and you can request a free review.