Ecommerce edge caching sounds simple: serve more responses close to shoppers and the store becomes faster. In practice, every currency, market, customer segment, experiment, inventory rule, and consent state can create another version of the same page. A cache that technically exists may deliver little value if its keys fragment traffic into thousands of low-volume variants.
The useful question is not “do we use a CDN?” It is “what proportion of eligible shopper requests are served quickly, correctly, and with an acceptable freshness risk?” That is the foundation of meaningful ecommerce edge-cache performance analysis.
Table of contents
- Why cache hit rate needs business context
- The cache variant explosion problem
- Ecommerce cache performance scorecard
- Freshness and trust controls
- How to run the analysis
- A 30-day improvement plan
Why cache hit rate needs business context
A global hit-rate average can hide the journeys that matter. A homepage cached at 98% may pull the average upward while product, search, and collection requests miss the cache whenever a shopper changes currency. The resulting dashboard looks healthy while high-intent traffic still waits on origin rendering.
Segment the metric by:
- page template and route family;
- country, market, and currency;
- anonymous versus authenticated state;
- device and connection class;
- campaign landing page;
- cache status: hit, miss, bypass, stale, or revalidated;
- origin response time;
- commercial outcome such as product view, add to cart, or purchase.
Google’s current Core Web Vitals guidance evaluates LCP, INP, and CLS at the 75th percentile, which is a useful reminder that averages are not enough. A cache strategy should improve the slower end of real shopper experience, not only produce an attractive mean. See the official Web Vitals thresholds and measurement guidance.
Recent platform evidence also shows why the work matters. Nuvemshop reported that its LCP pass rate rose from 57% to 96% and overall Core Web Vitals pass rate from 48% to 72%; the same-store mobile organic cohort recorded an 8.9% conversion-rate increase. The case study includes edge caching as one carefully controlled part of a broader performance program, not as an isolated guarantee. Read the Nuvemshop performance case study.
The cache variant explosion problem
Every cache key contains dimensions. Some are necessary; others arrive by accident.
| Cache-key dimension | Why teams add it | Fragmentation risk | Better control |
|---|---|---|---|
| full query string | preserve campaign or filter state | tracking parameters create nearly unique URLs | allowlist parameters that change content |
| cookie header | protect personalized output | analytics and consent cookies destroy reuse | vary only on commerce-relevant state |
| currency | show local prices | one object becomes many regional objects | normalize by supported price list |
| customer segment | support B2B or loyalty pricing | anonymous traffic can inherit excess variants | bypass or isolate authenticated routes |
| experiment ID | keep test assignment consistent | completed tests remain in the key | expire experiment dimensions |
| device type | deliver different markup | user-agent variety multiplies objects | prefer responsive shared markup |
Suppose a collection page varies across eight markets, four currencies, three customer states, two experiments, and two device classes. The theoretical space is 384 variants before query parameters enter the picture. Traffic rarely distributes evenly, so many objects expire before a second shopper requests them.
Measure requests per active cache object. A falling value often reveals fragmentation earlier than global hit rate. Also track how many variants receive only one request during their lifetime. Those one-hit objects consume cache and origin capacity without generating reuse.
Ecommerce cache performance scorecard
The following values are operating thresholds, not universal industry benchmarks. Set baselines from your own traffic and tighten them as the architecture improves.
| Metric | Definition | Diagnostic threshold | Owner |
|---|---|---|---|
| eligible edge hit rate | hits divided by requests safe to cache | investigate sustained decline by template | platform engineering |
| origin p75 TTFB on misses | server wait for uncached requests | alert when release baseline degrades | backend/platform |
| one-hit variant share | objects requested once before eviction | investigate rapid growth | edge engineering |
| stale-price incident rate | sessions shown outdated price | target zero material incidents | commerce operations |
| cache-key cardinality | distinct keys per canonical route | budget by template and market | architecture |
| revalidation failure rate | failed conditional refreshes | page immediately at checkout-impacting level | SRE |
| cache purge blast radius | objects invalidated per content change | reduce broad purges | content/platform |
Connect these metrics to business signals. Compare cache hits and misses within the same route, market, device, and traffic source. Then examine LCP, product engagement, add-to-cart rate, and checkout starts. This does not prove causation, but it identifies where controlled performance work is worth testing.
For a wider measurement model, use the ecommerce RUM-to-revenue scorecard and the latency budget framework.
Freshness and trust controls
Caching becomes dangerous when speed outruns truth. Price, promotion eligibility, inventory, delivery promise, and account-specific terms may have different freshness tolerances.
| Data type | Storefront tolerance | Recommended pattern |
|---|---|---|
| editorial copy | minutes or hours may be acceptable | long TTL plus targeted purge |
| product media | long-lived when URLs are versioned | immutable asset URL |
| base product price | short, market-dependent | controlled TTL plus revalidation |
| stock availability | often seconds to minutes | lightweight live check near intent |
| cart total | no shared-cache tolerance | calculate from authoritative service |
| B2B contract price | account-specific | private response or authenticated lookup |
| shipping promise | postcode and stock dependent | calculate after location is known |
Use layered truth. The product page can be cached aggressively while add-to-cart validates price and inventory against an authoritative service. If validation changes the offer, explain it clearly instead of silently failing.
Build a freshness SLO for each commercial field:
- Maximum acceptable age.
- Source of truth.
- Invalidation trigger.
- Fallback when the source is unavailable.
- Shopper message when certainty is reduced.
- Reconciliation process after recovery.
How to run the analysis
Start with seven to fourteen days of edge logs and real-user performance data. Normalize URLs to canonical route families, but retain the dimensions that genuinely change content. Join requests to page-view and commerce events using privacy-safe session or request identifiers.
Create four views:
1. Reuse view
Rank canonical routes by request volume, eligible hit rate, active variant count, and one-hit share. High-volume routes with weak reuse are the first candidates for cache-key simplification.
2. Miss-cost view
Multiply cache misses by origin compute time and p75 response delay. This exposes routes where misses are both common and expensive.
3. Freshness-risk view
List price, inventory, promotion, and delivery incidents alongside the cache state that served the page. Treat correctness as a guardrail, not a secondary metric.
4. Revenue-exposure view
Estimate affected sessions and revenue, but label the result as exposure rather than recovered revenue. A practical model is:
affected sessions × baseline conversion rate × average order value
Use the estimate to prioritize tests. Do not present it as guaranteed upside.
A 30-day improvement plan
Week 1: inventory and baseline
- Document every cache-key dimension.
- Classify routes as public-cacheable, privately cacheable, or dynamic.
- Baseline hit rate, key cardinality, origin p75, and freshness incidents.
- Identify query parameters and cookies that do not change content.
Week 2: simplify safely
- Remove irrelevant tracking parameters from cache keys.
- Normalize supported market and currency values.
- retire expired experiment dimensions;
- isolate authenticated and account-priced traffic.
- Add monitoring before changing TTLs.
Week 3: test high-value templates
- Run changes on one collection or product route family.
- Compare real-user LCP and origin load against a control.
- Monitor add-to-cart errors, price corrections, and stock conflicts.
- Test purge and rollback paths.
Week 4: operationalize
- Publish template-level cache budgets.
- Assign an owner to every varying dimension.
- Add cache cardinality checks to release review.
- Create a weekly performance-and-freshness scorecard.
The strongest edge strategy is selective. It maximizes safe reuse, limits unnecessary variants, protects commercial truth, and proves the result with real shopper data.
