Skip to content
Rendorix

SSR

SSR (server-side rendering) means your framework renders HTML on a server (Node, Cloudflare Workers, Deno, etc.) per request or at least per auth context. Rendorix image URLs can be injected at that moment—so exp, per-user assets, and A/B experiments are all on the table without a rebuild of the whole site.

When SSR is a good fit

Section titled “When SSR is a good fit”
  • Personalized home feeds, dashboards, inboxes—different users need different image src values.
  • Short-lived signed URLs where you refuse to embed month-long tokens in HTML (Signed URLs).
  • Session-gated content where the set of visible assets depends on permissions.
  • You already run a Node (or edge) runtime and can add a signing helper in one place.

If your page is static for 90% of users, consider a hybrid: prerender the shell and load signed URLs from a light API route (still not the HMAC secret in the client—only the result of server work).

Request-time signing

Section titled “Request-time signing”
  • Call the same canonical + HMAC flow as in Generating image URLs inside a server component loader, Remix loader, Next.js getServerSideProps / App Router server component data layer, Astro endpoint + frontmatter, or middleware-adjacent code.
  • Secrets come from the host’s environment (Cloudflare secrets, Lambda env, K8s secret, Doppler, etc.)—never from NEXT_PUBLIC_*-style vars.
  • Cost and latency: signing is cheap; HTML TTFB still adds SSR work—profile your app, not just HMAC microseconds.

Edge SSR (Workers, V8 isolates): confirm crypto APIs and HMAC libraries you use are supported in that runtime; Node’s crypto is not always identical in edge runtimes—test parity with your local signer.

Caching and personalization

Section titled “Caching and personalization”
  • HTML is hard to cache at a shared CDN when it varies per cookie or session—you often get private or no-store for HTML while static assets (JS/CSS) stay on the edge.
  • Image URLs can still be the same for the same (user, asset, preset) on successive requests—if so, CloudFront still caches the image bytes; if you mint a brand-new signed query every request, you bust image caches on purpose (sometimes necessary for security; expensive if abused).
  • Prefer stable image URLs for a stable (asset, transform) and tune signed TTL for threat model instead of randomizing the query for no reason (Caching).
Section titled “Tradeoffs (summary; link to Tradeoffs)”

Pros: Flexibility for per-user and short exp; no rebuild to change what images a page offers (when data changes).

Cons: Running servers (or always-on edge); HTML cache is trickier; per-request signing spikes need observability; more moving parts in dev and ops.

See Tradeoffs and compare with Static.

Section titled “Related reading”