Static Generation vs Edge SSR for Low-Traffic Qwik City: Cache-Header Behavior with Personalized routeLoader$
0 reputation · 28 Mar 2022, 21:16 UTC
0 reputation · 28 Mar 2022, 21:16 UTC
Choosing between Qwik City's static adapter (@qwik-city/static) and an edge SSR adapter (Vercel Edge, Netlify Edge, Cloudflare Workers) for a low-traffic site involves a direct cost-versus-freshness decision. Static generation yields zero server invocation costs and free CDN hosting, but content becomes stale until the next full rebuild — Qwik City v1.x does not yet ship incremental static regeneration (ISR). Edge SSR keeps every request fresh and enables personalization via routeLoader$ access to cookies and headers, yet each unique cache key bypasses the CDN and incurs per-invocation charges once free-tier limits are exceeded.
The core uncertainty lies in routeLoader$ cache-header semantics at the edge when personalized data is involved. Developers can return a Response with custom Cache-Control headers, but Qwik City does not document a built-in pattern for stale-while-revalidate or per-user cache keys. Misconfiguration — such as omitting Vary: Cookie — risks serving personalized content to the wrong visitor. Meanwhile, the lack of native ISR means any static-to-dynamic migration requires external webhook-orchestrated rebuilds, adding operational overhead.
For a workload averaging ~100 visits per day, the monthly cost difference between a fully static deployment and an edge SSR deployment with personalized loaders can shift from zero to pay-as-you-go once provider free tiers are consumed.
Cache-Control and Vary header combinations are safe for routeLoader$ responses that read authentication cookies at the edge?routeLoader$ logic that performs per-request personalization (e.g., A/B bucket assignment, user-specific feature flags)?A thoughtful contribution can make all the difference. Be the first to share one.
Use comments to ask for clarification. Post a solution as an answer.
5,790 reputation · 29 Mar 2022, 05:03 UTC
Returning a Response with Cache-Control from routeLoader$ does not guarantee the edge CDN will honor it; enforcement depends on the adapter and provider. For cookie-reading loaders in Qwik City v1.x, start with Cache-Control: private, no-store and add Vary: Cookie only if the cache key incorporates the session value, otherwise personalized HTML can leak to the wrong visitor. Because Qwik City v1.x has no documented ISR or stale-while-revalidate primitive, treat per-route freshness as rebuild-dependent until the adapter exposes otherwise. Verify by deploying two requests with different cookies and inspecting the actual response headers, not the dev-server output.