Frontend Beauty
ESC

Type to search the knowledge base.

Edge Rendering Tradeoffs

System design tradeoffs for edge SSR/ISR — latency, cache keys, personalization, cold starts, and when not to.

advanced4 min read
  • system-design
  • interview
  • architecture
  • edge
  • ssr

Scope the problem

Edge rendering runs HTML generation (or assembly) on CDN POPs close to users. Interviews test whether you understand cacheability, personalization, and operational limits — not vendor marketing.

In scope: SSR at edge, ISR/stale-while-revalidate, streaming, A/B at edge, failure modes.

Out of scope: writing a JS runtime from scratch.

Why teams reach for edge

Benefit Mechanism
Lower TTFB compute near user
Dynamic HTML without origin hop for each request or cached
Geo personalization country header at edge

Spectrum of approaches

Static SSG  →  ISR/SWR CDN cache  →  Edge SSR per request  →  Origin SSR
   fastest           hybrid              flexible              full data center
Mode Cache Personalization Cost profile
SSG perfect none at build cheapest runtime
ISR TTL / on-demand revalidate weak sweet spot many sites
Edge SSR optional short TTL strong CPU per request
Client only N/A strong weak SEO/LCP

Architecture sketch

User → POP
        ├─ cache HIT: HTML
        └─ MISS/BYPASS: Edge function
                         ├─ fetch data (origin API / KV / edge DB)
                         ├─ render React/Vue stream
                         └─ set Cache-Control

Cache key design (the real problem)

HTML personalization fragments caches:

cache key ≈ URL + selected request variance

Variance sources:

  • Cookie session / experiment bucket
  • Accept-Language
  • Auth state
  • Geo

Rules:

  • Public marketing pages: no user cookies in key; personalize client-side or edge only for anonymous segments
  • Authenticated app shells: often Cache-Control: private, no-store for HTML
  • Logged-out product pages: cacheable with ISR

Bad design: Vary: Cookie on everything → near-zero hit ratio.

Data access from the edge

Source Tradeoff
Origin HTTP API simple; adds hop (still may beat browser waterfall)
Edge KV/Config fast reads; eventually consistent
Edge SQL/global DB emerging; regional limits
Precomputed HTML in object store very fast; rebuild pipeline

Timeouts must be tight; fail to stale cache or skeleton.

Streaming SSR

Stream shell early → suspend for slow widgets → progressive HTML. Improves TTFB perception; still careful with SEO chunks and SEO bots.

Cold starts & limits

  • Isolate CPU/time budgets (ms–seconds)
  • Bundle size for edge functions matters
  • Not all Node APIs available — design dual runtime or use compatible subset
  • Long data processing doesn’t belong on edge — precompute

Personalization patterns that keep hit rates

  1. Edge decides segment (geo, A/B bucket cookie) with small cardinality → cache per segment
  2. Shell cached, islands personalized client-side
  3. ESI-like composition (vendor-specific) for fragments

Observability

  • Hit ratio, TTFB p95 by POP
  • Origin fetch failures from edge
  • Render CPU time
  • Error budget → fallback static

Security

  • SSRF risk if edge fetches user-provided URLs
  • Header spoofing: trust only platform geo headers
  • Auth at edge: validate JWT with care (key rotation)

When not to use edge SSR

  • Highly personalized dashboards (low cache value)
  • Heavy CPU renders
  • Strong consistency with primary DB in one region
  • Team can’t operate dual runtime

Prefer SPA/BFF origin for app UI; edge for marketing + PDP-like content.

Tradeoffs summary

  1. TTFB vs hit ratio
  2. Freshness vs cost (ISR TTL)
  3. Edge complexity vs origin simplicity
  4. Streaming UX vs caching granularity

Interview close

Define content class → choose SSG/ISR/edge-SSR → design cache keys with low cardinality → data fetch timeouts and stale fallback → measure hit ratio. Explicitly say personalization is the enemy of cache unless segmented carefully.

Further reading