Client-Side Rendering (CSR), Server-Side Rendering (SSR), and Static Site Generation (SSG)

Remember the early days of the web, when a “web app” was often just a collection of static HTML files hyperlinked together? Those times are a distant memory. Today, one of the most critical architectural decisions you’ll make as a web developer isn’t just what content to display, but how and when that content is rendered into a usable page. This choice fundamentally impacts performance, user experience, SEO, and development complexity.

We’re diving deep into the three core rendering paradigms that dominate modern web development: Client-Side Rendering (CSR), Server-Side Rendering (SSR), and Static Site Generation (SSG). We’ll unpack how they work, weigh their pros and cons, and look at practical implementations in a modern framework like Next.js. By the end, you’ll be equipped to choose the right strategy for your next project with confidence.

The Classic: Client-Side Rendering (CSR)

Client-Side Rendering is the bedrock of the Single-Page Application (SPA). It’s the approach that made web applications feel more like native desktop apps for the first time.

How it Works

In a pure CSR model, the server’s job is minimal. It sends a nearly empty HTML file (often called a “shell”) along with a hefty JavaScript bundle to the browser.

1. 1. User requests a page.

1. 1. Server sends index.html and app.js.

1. 1. The browser parses the HTML and starts downloading the JavaScript.

1. 1. Once the JavaScript is downloaded and executed, it takes over. It makes API calls to fetch data and then dynamically renders the content into the DOM.

Think of it like buying flat-pack furniture. You receive a box (the HTML shell) and a complex set of instructions (the JavaScript bundle). Your living room (the browser) is where all the assembly (rendering) happens. Subsequent “page” navigations are just the JavaScript code swapping out components and fetching new data, without a full page refresh.

Pros and Cons

• • Pros:
    • • Rich Interactivity: Once loaded, the UI can be incredibly fast and responsive, as DOM manipulations happen directly on the client without network latency.
    • • Fast Subsequent Navigation: After the initial load, navigating between “pages” is near-instantaneous.
    • • Robust Ecosystem: Powers many popular frameworks like React (with create-react-app), Vue, and Angular.

• • Cons:
    • • Slow Initial Load: The user sees a blank white screen until the entire JavaScript bundle is downloaded, parsed, and executed. This leads to a high Time to Interactive (TTI).
    • • Poor SEO: Search engine crawlers traditionally had trouble executing JavaScript. While they’ve gotten better, they may still see an empty HTML shell, which can negatively impact indexing and ranking.
    • • Dependency on JavaScript: If the user has JavaScript disabled or it fails to load, the site is completely broken.

Illustrative Code Snippet

This classic React useEffect pattern is the heart of CSR data fetching. The component mounts, and only then does it go looking for its data.

javascript
// A typical data-fetching component in a CSR React app
import React, { useState, useEffect } from ‘react’;

function UserProfile({ userId }) {
const [user, setUser] = useState(null);
const [isLoading, setIsLoading] = useState(true);

useEffect(() => {
// This code runs in the browser AFTER the initial render
const fetchUserData = async () => {
setIsLoading(true);
const response = await fetch(/api/users/${userId});
const data = await response.json();
setUser(data);
setIsLoading(false);
};

fetchUserData();

}, [userId]); // Re-run if userId changes

if (isLoading) {
return

;
}

if (!user) {
return

;
}

return (

);
}

The Comeback Kid: Server-Side Rendering (SSR)

Before SPAs took over, almost everything was server-rendered. Modern SSR, however, is a sophisticated evolution that combines the benefits of a server-generated page with the rich interactivity of a client-side app through a process called hydration.

How it Works

With SSR, every request for a page is a new event for the server.

1. 1. User requests a page.

1. 1. The server “wakes up,” runs the application code, fetches any necessary data from a database or API, and renders the complete, fully-formed HTML page.

1. 1. This complete HTML page is sent to the browser for a fast First Contentful Paint (FCP).

1. 1. The browser then downloads the JavaScript bundle in the background.

1. 1. Once the JavaScript loads, it “hydrates” the static HTML, attaching event listeners and making the page interactive without re-rendering the entire DOM.

This is like ordering a pre-assembled bookshelf. It arrives ready to use immediately. The delivery person (JavaScript) might come back later to bolt it to the wall (attach interactivity), but you can start putting books on it right away.

Pros and Cons

• • Pros:
    • • Excellent SEO: Search engines receive a fully-rendered HTML page, making content easy to crawl and index.
    • • Fast FCP: Users see content almost immediately, which greatly improves perceived performance.
    • • Ideal for Dynamic Data: Perfect for content that is personalized or changes frequently, like a user dashboard or a social media feed.

• • Cons:
    • • Slower TTFB (Time to First Byte): The server has to perform computations and data fetching for every request, which can delay sending the first byte of data.
    • • Higher Server Load: This “compute-on-request” model requires more powerful and costly server infrastructure compared to simply serving static files.
    • • Full Page Reloads on Navigation: While modern frameworks handle this gracefully, the underlying mechanism is still a new server request for each page.

Code Example in Next.js

Next.js makes SSR straightforward with the getServerSideProps function. Any code inside this function runs exclusively on the server for each incoming request.

javascript
// pages/posts/[id].js – A server-rendered page in Next.js

// This function runs on the server for every request
export async function getServerSideProps(context) {
const { id } = context.params;

// Fetch data from an external API or database
const res = await fetch(https://api.example.com/posts/${id});
const post = await res.json();

// Pass data to the page via props
return { props: { post } };
}

function PostPage({ post }) {
// The ‘post’ prop is already populated with data from the server
return (

{post.author}

{post.content}

);
}

export default PostPage;

The Performance King: Static Site Generation (SSG)

SSG takes the “pre-rendering” idea of SSR and pushes it to its logical extreme. Instead of rendering a page on every request, why not render every possible page once, ahead of time?

How it Works

The magic of SSG happens entirely at build time.

1. 1. During your deployment process (e.g., next build), the framework runs your code.

1. 1. It fetches data for all your pages and generates a final, static HTML file for each one.

1. 1. This collection of HTML, CSS, and JS files is then deployed to a Content Delivery Network (CDN).

1. 1. When a user requests a page, the CDN simply serves the pre-built HTML file closest to them. There’s no server computation involved.

This is akin to mass-producing furniture and stocking it in warehouses worldwide. When a customer orders one, it’s shipped from the nearest location, making delivery incredibly fast.

Pros and Cons

• • Pros:
    • • Blazing-Fast Performance: Serving static files from a CDN is the fastest possible way to deliver a web page. TTFB is near-instant.
    • • Highly Secure and Reliable: With no live database connections or server-side code execution at request time, the attack surface is dramatically reduced.
    • • Excellent SEO: Just like SSR, crawlers get perfect, fully-rendered HTML.
    • • Cheap to Host: Hosting static files is incredibly inexpensive or even free on platforms like Vercel, Netlify, and GitHub Pages.

• • Cons:
    • • Build Times: For very large sites (tens of thousands of pages), the initial build process can become slow.
    • • Stale Content: Content is only as fresh as the last build. To update a single blog post, the entire site (or a portion of it) must be rebuilt and redeployed. This is unsuitable for highly dynamic content.

Code Example in Next.js

In Next.js, SSG is achieved with getStaticProps. For dynamic routes (like a blog post URL), you also need getStaticPaths to tell Next.js which pages to generate at build time.

javascript
// pages/products/[slug].js – A static-generated page in Next.js

// 1. Tell Next.js which paths to pre-render at build time
export async function getStaticPaths() {
const res = await fetch(‘https://api.example.com/products’);
const products = await res.json();

const paths = products.map((product) => ({
params: { slug: product.slug },
}));

return { paths, fallback: false }; // fallback: false means 404 if path doesn’t exist
}

// 2. Fetch data for each specific page at build time
export async function getStaticProps({ params }) {
const res = await fetch(https://api.example.com/products/${params.slug});
const product = await res.json();

return { props: { product } };
}

// 3. The component receives the pre-fetched props
function ProductPage({ product }) {
return (

);
}

export default ProductPage;

The Hybrid Evolution: Incremental Static Regeneration (ISR)

What if you could get the speed of SSG with the freshness of SSR? That’s the promise of ISR. It’s an SSG feature (pioneered by Next.js) that allows you to rebuild static pages automatically in the background after a certain time has elapsed.

By adding a revalidate key to getStaticProps, you tell the server to serve the stale page, but trigger a rebuild in the background. The next user to visit gets the newly generated page.

javascript
export async function getStaticProps() {
const res = await fetch(‘https://api.example.com/latest-news’);
const news = await res.json();

return {
props: { news },
// Re-generate this page in the background at most once every 60 seconds
revalidate: 60,
};
}

Conclusion

The debate between CSR, SSR, and SSG is no longer about choosing one “best” method. Modern meta-frameworks have turned this into a strategic, per-page decision.

Here’s your cheat sheet:

• • Client-Side Rendering (CSR): Choose for highly interactive, complex applications that live behind a login where SEO is not a concern (e.g., a SaaS dashboard, a photo editor).

• • Server-Side Rendering (SSR): Choose for pages that need to be SEO-friendly and display highly dynamic, personalized, or real-time data (e.g., a user’s account page, a stock ticker page).

• • Static Site Generation (SSG): This should be your default choice for performance. Use it for any page where the content doesn’t change with every user request (e.g., marketing pages, blog posts, documentation, product listings). Use ISR to keep the static content fresh.

The beauty of the modern web is that you don’t have to go all-in on one strategy. In a single Next.js application, your marketing homepage can be SSG, your blog can use ISR, your user dashboard can be SSR, and a complex analytics section could be pure CSR. By understanding the trade-offs, you can architect faster, more resilient, and more effective web applications.

Frequently Asked Questions

Q1: Which rendering method is definitively the best for SEO?
Both SSR and SSG are excellent for SEO because they deliver fully-rendered HTML to the search engine crawler. CSR is the weakest, as it relies on the crawler’s ability to execute JavaScript, which can be inconsistent. For content-driven sites where SEO is paramount, SSG is often preferred due to its superior performance, which is also a key ranking factor.

Q2: Can I really mix different rendering strategies in a single application?
Absolutely. This is the primary advantage of using a modern meta-framework like Next.js, Nuxt.js (for Vue), or SvelteKit. They are designed to allow you to choose the rendering method on a page-by-page basis, giving you the flexibility to optimize each part of your application according to its specific needs.

Q3: Is Client-Side Rendering dead?
Not at all. CSR remains the ideal choice for web applications that mimic desktop software, such as project management tools (like Jira or Trello), design software (like Figma), or any complex, stateful interface where initial load time is less critical than the rich interactivity that follows. It’s often used for sections of an app that are behind a login wall.

Q4: What is “hydration” and why is it important for SSR and SSG?
Hydration is the client-side process that makes a server-rendered or statically-generated page interactive. The server sends plain, non-interactive HTML for a fast initial display. Then, the browser downloads the JavaScript, which runs and attaches event listeners (like onClick) to the existing HTML elements without re-rendering them. This “breathes life” into the static page, making it a fully-fledged SPA. Without hydration, an SSR page would look right but wouldn’t be clickable or interactive.