What are the performance trade-offs of SSR vs SSG in a high-traffic production app?

When traffic spikes, SSR systems face proportional increases in server load. Each request consumes CPU and memory to render the page, potentially leading to a death spiral as servers become overloaded and response times increase. With auto-scaling, this means provisioning enough capacity for peak traffic—often 2-3x average load. Database connections multiply with each request, requiring connection pooling and careful resource management. Even with aggressive caching at the CDN or application layer, personalized SSR often bypasses caches, making it vulnerable to traffic surges. High-traffic SSR apps typically require sophisticated load balancing, distributed caching, and database read replicas to maintain performance.

The primary performance trade-off for SSG is the complexity of keeping content fresh. With pure SSG, content updates require full site rebuilds—impractical for large sites at high-traffic scale. ISR solves this but introduces its own performance considerations: background regeneration consumes server resources, and the first request after a revalidate window experiences a slight delay while the page regenerates. On-demand ISR via webhooks can trigger updates instantly but requires additional infrastructure. For sites with millions of pages, you must carefully balance pre-rendering (fast but costly builds) with on-demand generation (slower first visits but efficient builds).

Consider a large e-commerce platform with 500,000 products and 50 million monthly pageviews. With SSR, each product page view consumes server resources, requiring massive auto-scaling during sales events (Black Friday traffic 10x normal). Database load would necessitate dozens of read replicas, and response times would degrade under peak load. With SSG/ISR, the site pre-renders 50,000 popular products at build time, generating the rest on-demand. During a sales event, 95% of traffic hits pre-rendered pages served from CDN, with zero origin impact. The remaining 5% trigger on-demand generation, easily handled by minimal server capacity. Infrastructure costs drop by 80-90%, and page load times improve from 600ms to under 100ms.

ISR has emerged as the preferred approach for high-traffic production apps because it bridges the performance gap. By pre-rendering pages at build time and updating them in the background, ISR achieves SSG-level performance for most requests while maintaining near real-time freshness for content updates. The key insight is that most traffic goes to a subset of pages—the Pareto principle applies. Pre-render the 20% of pages that get 80% of traffic, generate the rest on-demand, and use webhooks to update critical pages instantly. This gives you the best of both worlds: CDN performance with server-generated freshness when needed.