A 304 Not Modified response transfers less data than a full 200, but it still needs a network round trip and often reaches the origin before the browser can reuse its local copy. On a product journey with dozens of revalidated assets, those “small” checks can delay repeat navigation and increase infrastructure work.
What we see in ecommerce performance analysis is that teams optimize first visits while assuming returning shoppers are automatically fast. In practice, vague cache headers, unstable URLs, broad invalidations, and personalized HTML can make repeat visits unexpectedly expensive. The answer is not “cache everything.” It is a freshness policy tied to the business risk of each resource.
Table of Contents
- Keyword decision and search intent
- Understand fresh, stale, and revalidated responses
- Classify ecommerce resources by freshness risk
- Build a repeat-visit cache scorecard
- Avoid invalidation and personalization traps
- A practical implementation plan
- EcomToolkit point of view
Keyword decision and search intent
- Primary keyword: ecommerce cache revalidation performance
- Secondary keywords: 304 response performance, ecommerce browser caching, ETag cache control, repeat visit page speed
- Search intent: Technical and operational
- Funnel stage: Mid funnel
- Page type: Storefront performance implementation guide
- Why EcomToolkit can compete: generic caching articles explain headers; ecommerce teams need separate policies for immutable assets, product content, price, inventory, cart, and account data.
Understand fresh, stale, and revalidated responses
A browser can reuse a fresh cached response without asking the server. Once stale, it may send a conditional request with If-None-Match or If-Modified-Since. The server returns 304 when the representation has not changed, or a new 200 when it has. A validator saves transfer bytes, but not the request latency.
The HTTP caching standard defines freshness, validators, and directives such as max-age, no-cache, and must-revalidate. Review RFC 9111 and MDN’s practical HTTP caching guide. Note that no-cache permits storage but requires validation before reuse; it does not mean “do not store.” no-store is the stricter directive.
| Response state | Network request | Body transfer | Typical implication |
|---|---|---|---|
| fresh cache hit | no | no | fastest repeat use |
304 revalidation | yes | no | latency remains |
new 200 after validation | yes | yes | changed representation |
| cache miss | yes | yes | first use or eviction |
Inspect actual browser behavior rather than inferring it from CDN hit rate. Edge caching and browser caching are different layers.
Classify ecommerce resources by freshness risk
Use business semantics to assign policy:
| Resource | Preferred pattern | Main risk |
|---|---|---|
| hashed CSS and JavaScript | long max-age, immutable | deploying changed bytes at same URL |
| versioned fonts and icons | long-lived immutable | license or asset replacement |
| product images | versioned URL with long freshness | stale merchandising image |
| category or editorial HTML | short freshness plus revalidation | outdated campaign content |
| product HTML | controlled freshness and targeted purge | stale price or availability |
| inventory endpoint | short, explicit policy | overselling or false stockout |
| cart and account data | private and user-specific | cross-user leakage |
Do not place private responses into a shared cache without a verified cache key and platform-safe design. A fast response that exposes another customer’s state is a critical failure.
Hashed filenames make long browser caching practical: when bytes change, the URL changes. HTML can then reference the new asset while old versions expire naturally. Keep previous assets available through the deploy transition so an older HTML document does not request a file already removed.
Build a repeat-visit cache scorecard
Test cold, warm, and revalidation journeys separately. A normal performance run often disables cache or starts with an empty profile, hiding returning-customer behavior.
| Metric | Formula | What it reveals |
|---|---|---|
| fresh reuse rate | cache-served requests without network / eligible repeat requests | true browser-cache value |
| revalidation rate | conditional requests / eligible cached requests | round-trip dependency |
| revalidation latency p75 | p75 completion time for conditional requests | geographic and origin cost |
| byte reuse rate | avoided repeat bytes / eligible repeat bytes | transfer efficiency |
unnecessary 200 rate | unchanged resources returned fully / conditional requests | validator instability |
| stale business event rate | confirmed stale price, stock, or campaign exposures / exposures | correctness guardrail |
| invalidation blast radius | purged objects / objects that actually changed | operational efficiency |
Segment by template, device, region, release, and customer state. Report critical-path requests separately: a revalidated analytics file is not equivalent to revalidated CSS blocking the first render.
Capture Server-Timing, cache status, response age, and validator behavior where available. Real User Monitoring will not expose every request header, so combine privacy-safe field timings with synthetic repeat-journey tests and edge logs.
Avoid invalidation and personalization traps
Weak or changing ETags can force full downloads. Last-Modified checks may be too coarse for rapidly changing resources. Validators should reflect representation bytes or a reliable version—not a timestamp regenerated on every request.
Broad purges protect freshness but destroy hit rate and increase origin load. Purge product pages, collections, feeds, and fragments using a dependency map. A price change might affect the PDP, relevant collections, recommendations, search results, structured data, and a feed; it should not evict every static asset.
Personalization multiplies variants. If the cache key varies on an entire cookie header, nearly every shopper can produce a unique object. Allow only the dimensions that genuinely change the representation, and keep volatile customer state in private or client-fetched layers.
stale-while-revalidate can serve a stale response while updating it in the background. It works well for content where brief staleness is acceptable, but is risky for inventory, price, promotion eligibility, and legal messaging unless the allowed stale window matches the business commitment.
An anonymous retailer found many repeat product views still waited on conditional requests for unchanged theme assets. Asset URLs were stable across releases and headers forced validation. Moving built assets to content-hashed URLs allowed long-lived fresh reuse, while product data kept a separate short-lived policy. The example is qualitative; no synthetic conversion gain is claimed.
A practical implementation plan
- Inventory cache headers, validators, cookies, CDN rules, and invalidation paths by resource type.
- Record cold, warm, and stale-repeat waterfalls for homepage, collection, PDP, cart, and account journeys.
- Give built assets content hashes and long immutable freshness; preserve rollback compatibility.
- Define price, stock, campaign, and account freshness according to commercial risk.
- Limit cache-key dimensions and test anonymous, logged-in, localized, and consent states.
- Replace global purges with dependency-aware invalidation where the platform supports it.
- Add stale-content incidents and revalidation latency to the release scorecard.
Use the CDN cache-hit and origin-load framework for the shared edge layer, and the inventory freshness guide for availability-sensitive decisions.
EcomToolkit point of view
The purpose of caching is not the highest possible hit rate. It is fast reuse within a clearly defined freshness promise. Immutable assets, stable validators, narrow cache keys, and targeted invalidation make returning journeys faster without allowing price, stock, or customer state to become dangerously stale.
Explore more performance frameworks in the EcomToolkit resources library.
