A deep dive into SSR, SSG, and client-side rendering—their costs, benefits, and how we evolved from simple websites to today’s complex rendering landscape.

The SSR Cost Problem

Server-Side Rendering has become the default choice for many new projects, but before jumping on the bandwagon, let’s talk about what it’s actually costing you—and whether you really need it.

The rise of SSR frameworks like Next.js has made server-side rendering feel inevitable, but the reality is more nuanced. Every rendering choice is fundamentally about who pays for computation: your servers or your users’ devices.

SSR introduces a fundamental cost structure change that many developers don’t fully consider:

SPA Economics:

SSR Economics:

This isn’t just a technical decision—it’s a business strategy decision.

How We Got Here: The Rendering Evolution

To understand why we have these choices, we need to look at how web development evolved. The traditional distinction between “websites” and “web apps” has completely broken down.

The Old Categories

The traditional thinking was simple:

The Modern Reality

Today’s applications exist in a gray area. Consider a modern e-commerce platform built with Next.js:

The answer to “is this a website or a web app?” doesn’t matter anymore. It’s whatever it needs to be, page by page, feature by feature. This flexibility led to our current rendering complexity.

The SPA Revolution: Crowdsourcing Computation

For developers coming from the Single Page Application (SPA) world, the concept is beautifully simple:

  1. Server delivers a minimal HTML shell
  2. Browser downloads JavaScript bundles
  3. JavaScript builds the entire user interface
  4. Application becomes interactive
<!-- What the server sends -->
<div id="root"></div>
<script src="app.js"></script>

<!-- What JavaScript creates -->
<div id="root">
  <h1>Welcome to Our App</h1>
  <p>Loading your personalized content...</p>
</div>

SPAs are, in many ways, brilliant. They essentially crowdsource computational work to users’ devices. Every visitor becomes a tiny server, rendering your application using their own CPU and memory. From a cost perspective, it’s genius—you’re getting free labor from every user’s device.

Enter Server-Side Rendering: The Plot Twist

Server-Side Rendering (SSR) flips this model:

  1. Browser requests a specific page
  2. Server runs your application code server-side
  3. Server generates complete HTML
  4. Browser receives fully-rendered page
  5. JavaScript “hydrates” the existing HTML
<!-- What the server sends (already complete!) -->
<div id="root">
  <h1>Welcome back, Sarah!</h1>
  <p>Here are your recent orders...</p>
  <div class="order-list">
    <!-- Fully rendered content -->
  </div>
</div>
<script src="app.js"></script>

The key insight: SSR is like running your SPA on the server first, then sending the results to the browser.

The Strategic Framework: When to Choose What

Understanding the cost implications helps inform better architectural decisions:

Choose SPA when:

Choose SSR when:

The Hybrid Approach: Best of Both Worlds

Modern frameworks like Next.js allow you to be surgical about your choices:

// Static for SEO and performance
export async function getStaticProps() {
  return { props: { posts: await fetchBlogPosts() } };
}

// Server-side for dynamic, SEO-critical content
export async function getServerSideProps() {
  return { props: { user: await fetchUserData() } };
}

// Client-side for interactive features
useEffect(() => {
  // Handle real-time updates
}, []);

This lets you optimize each page or feature for its specific needs and constraints.

The Middle Ground: Static Site Generation

Static Site Generation (SSG) represents perhaps the most balanced solution of all. It gives you:

You’re essentially doing the computational work once at build time, then serving the results infinitely at near-zero cost.

Real-World Examples: How Companies Choose

Consider how different companies approach this:

Advanced Rendering Techniques

We’re moving toward even more sophisticated approaches:

Conclusion: There’s No Universal Right Answer

The key insight is recognizing that rendering strategy is fundamentally about who pays for computation: your servers or your users’ devices. Both approaches have their place, and the best applications use both strategically.

Instead of defaulting to SSR, make informed decisions based on:

In the end, the “best” approach is the one that serves your users effectively while maintaining sustainable economics for your business. Sometimes that means crowdsourcing computation to users’ devices. Sometimes it means investing in server-side rendering. Often, it means being smart about using both.

The web has evolved beyond simple categories, and our architectural thinking should evolve with it.

What’s your experience with SPA vs SSR tradeoffs? Have you noticed the cost implications in your own projects? Share your thoughts and war stories in the comments below.