# Cache key sprawl: why your edge hit ratio is lower than you think

Source: https://edgecommercejournal.com/blog/2026-10-01-cache-key-sprawl-edge.html

Oct 1, 2026 - Edge Commerce Journal


Your most popular product page has ten thousand cached copies at the edge, and nine thousand of them are the same page. The culprit is the query string: every UTM tag, sort parameter, and session token creates a distinct cache key, so identical content gets stored, expired, and revalidated as if it were different pages. The fix is not more edge capacity. It is teaching your cache which parts of the URL actually change the response.

## How one page becomes ten thousand cache keys

Take a category page at /collections/running-shoes. A shopper arrives from an ad with ?utm\_source=newsletter&utm\_medium=email&utm\_campaign=october. Another comes from social with a different utm\_source. A third sorts by price with ?sort=price-asc, a fourth by newest, a fifth clicks through with a session parameter your analytics tool appended. Each of those URLs is a different cache key. The HTML served is nearly identical, but the edge does not know that. It caches each variant separately, and every variant has to be fetched from origin, stored, and eventually revalidated on its own schedule.

The sprawl compounds with TTLs. If your category page has a five-minute cache lifetime, the edge is not refreshing one page every five minutes. It is refreshing every variant every five minutes, and each refresh is an origin request. A page with forty live variants generates forty origin fetches per TTL window instead of one. Your origin team sees load that scales with your marketing campaigns, and the cache hit ratio sits at sixty percent while the content is 99 percent identical across variants.

## The parameters that matter, and the ones that do not

Not every query parameter is noise. Some genuinely change the page: sort orders, page numbers, filters, and variant selections produce different content and need different cache entries. The problem is the parameters that change nothing: UTM tags, click IDs, referral codes, session tokens, and the assorted tracking debris that marketing tools append to URLs. These should never be part of a cache key.

The audit is straightforward. Pull your top fifty URLs by origin request volume and list the distinct query strings hitting each one. For most storefronts, the pattern is obvious within minutes: a handful of tracking parameters account for the majority of key variants. UTM parameters alone (utm\_source, utm\_medium, utm\_campaign, utm\_term, utm\_content) routinely multiply popular pages into dozens of cache entries. Click identifiers from ad platforms add more. The rule of thumb: if a parameter does not change what the shopper sees, it should not change the cache key.

## Normalization rules that actually work

The standard fix is cache key normalization at the edge: strip or ignore the parameters that do not affect content before computing the key. Most edge platforms support this natively, either as a query-string whitelist (only these parameters form the key) or a blacklist (ignore these parameters). The whitelist approach is safer for storefronts. Declare the parameters that genuinely change content, sort, page, filter, variant, and let everything else fall out of the key.

Two details matter. First, parameter order. ?sort=price&page=2 and ?page=2&sort=price are the same page but different strings, so normalize the order or hash the sorted parameters. Second, case and encoding: a parameter value that arrives percent-encoded on one request and literal on another creates two keys for the same page. Normalization should canonicalize both. These sound like edge cases until you see the variant counts, and then they look like the main event.

## What to do about parameters you cannot strip

Some parameters resist the simple treatment. Personalization tokens genuinely change the response, but they often do not need to: a session ID in the query string that only affects an analytics beacon means the page content is shared while the key says it is unique. The right move is to move session state out of the URL entirely, into cookies or headers, where it never touches the cache key. Query strings are the worst place for session data precisely because they poison caching.

A/B test parameters are the other tricky case. If variant assignment lives in the URL, every variant of every page multiplies the key space. The cleaner pattern is to assign the test bucket in a cookie at the edge and vary the cache on that cookie instead of the query string. You still get per-variant caching, but the key space stays bounded by the number of variants rather than exploding with every tracking parameter combination.

## Measuring the win

After normalizing, watch two numbers: cache hit ratio on your top pages, and origin requests per TTL window for a single popular URL. The hit ratio should climb, but the more telling metric is the second one. If a category page was generating forty origin fetches per five-minute window and now generates three, the sprawl is gone. The remaining fetches correspond to genuinely distinct variants: the sort orders and filters that actually change content.

One caution: do not normalize blindly on pages with real variant parameters. Stripping the sort parameter from a category page key means every shopper sees the default sort regardless of what they clicked. The whitelist must be built from knowledge of what each parameter does, not from a generic strip-everything rule. Get the product and merchandising teams to confirm which parameters change the rendered page, and encode exactly that list. Cache key design is a product decision disguised as an infrastructure setting, and it deserves the same care you would give any other part of the storefront.

## Frequently asked questions

### What is the main takeaway on cache key sprawl: why your edge hit ratio is lower than you think?

The main point is to approach cache key sprawl: why your edge hit ratio is lower than you think with a clear goal, a modest starting step, and enough consistency to judge the result fairly. Most problems come from rushing, layering too many changes at once, or copying a routine that was built for a different situation.

### How long should I try this before judging it?

Give a sensible approach two to four weeks of consistent use unless it causes pain, damage, or a clear step backwards. Keep a short note of what you did and what changed, because memory alone tends to overrate single good or bad days.

### What is the most common mistake people make here?

Doing too much too soon is the usual mistake. Starting gently, changing one variable at a time, and stopping to reassess when something irritates, breaks, or stops working will save more time and money than any single product or trick.

### When should I get professional help instead?

Get professional help if you notice pain, sudden or severe symptoms, damage that keeps worsening despite gentle care, or any safety concern. Guides help with ordinary decisions, but persistent or alarming problems deserve an in person assessment.