Comment #7

One reason I think a Shopify Hydrogen community like this is useful is that many real implementation decisions are difficult to capture in official documentation alone. Developers often need practical examples of caching strategies, Storefront API tradeoffs, deployment choices, SEO issues, routing patterns, and performance problems that only become obvious after building a real headless storefront. A focused Hydrogen forum can collect those lessons in one searchable place, help developers compare different approaches, and make it easier for new teams to avoid repeating the same mistakes. Over time, that kind of shared knowledge can become just as valuable as the documentation itself.

The cache key problem shows up in another place too: personalization. If a loader reads a customer token to decide what to render, the response can no longer be shared, and one logged-in visitor can quietly poison a cached route for everyone else if the vary logic is loose. The practical split I keep landing on is keeping loaders anonymous by default and hydrating anything customer-specific from a client component after paint, or from a separate endpoint with its own no-store policy. That costs a round trip, but it means the server-rendered HTML stays cacheable and the cache key stays boring. Skeptical about how well that holds once shops want logged-in pricing on collection pages.

One area that seems worth testing is how Shopify Hydrogen handles data freshness across different route types. Product inventory and pricing probably need a much shorter cache lifetime than collection pages, navigation, or editorial content. I’m curious whether others prefer route-level cache policies or a more centralized Storefront API caching strategy, especially when React Router loaders and edge caching are both involved.

That custom header approach has a lurking variant that bit me on a recent build. Anything the loader computes from request context, not just identity, changes the response: serving an estimated delivery window on collection cards derived from `localization.country` or a warehouse lookup means two visitors hitting the same

I would also separate data freshness from HTML freshness. Product inventory may need a short lifetime, while navigation, editorial blocks and some collection data can often live much longer at the edge. That makes invalidation more deliberate and gives the origin fewer reasons to participate in every request.

Leo, that variant extends further into anything the loader derives from time rather than identity. We served a promotional banner from a loader that checked whether a sale window had passed, and because the response carried a long edge TTL, shoppers kept seeing expired pricing well after the cutoff. The fix was keeping the decision out of the cached HTML entirely: render a neutral shell, then have a tiny client fetch resolve the promotion state against a short-lived endpoint. The same pattern handles delivery estimates and stock messaging, since those depend on clocks and warehouse state that no cache key can capture. Worth noting that cache-hit ratio and time-to-first-byte observability need to be tracked separately from loader latency, otherwise a stale-content incident looks like a slow origin.

One thing I would test early is how much data each route actually needs. It is easy to request a large product payload just because the Storefront API makes it available. Smaller queries, predictable loaders and a good image strategy usually matter more to real storefront speed than adding another framework abstraction.

There's a related trap in how product data itself gets shaped for faceted navigation. If collection loaders pull full variant arrays just to compute which filter values exist, every facet change drags a payload the page never renders, and stale facet counts linger in cache alongside the products. I've had better luck fetching filter metadata through a separate query keyed by collection handle and a short TTL, then letting product results stay lean and long-lived. Search analytics from Shopify's Search & Discovery app also feed back into which facets are worth surfacing, so the query design and the merchandising config drift apart fast unless someone owns both.