What is the difference between SSR and CSR?

Server-Side Rendering (SSR) renders the HTML on the server before sending it to the client, improving initial load time and SEO. Client-Side Rendering (CSR) sends an empty HTML shell and relies on JavaScript to render the UI in the browser.

When should I use Static Site Generation (SSG)?

Use SSG when your content doesn't change frequently on a per-request basis (e.g., blogs, documentation, marketing pages). It offers the best performance because HTML is generated once at build time and served via a CDN.

What is Incremental Static Regeneration (ISR)?

ISR combines the benefits of SSG and SSR. It allows you to build static pages at build time but also update them in the background as traffic comes in, without rebuilding the entire site.

What is Server-Side Rendering (SSR)?

Understanding modern web rendering patterns: SSR vs CSR vs SSG vs ISR.

For decades, the web was inherently server-rendered. A user navigated to a URL, the server assembled an HTML string, and the browser painted it. Then came the era of Single Page Applications (SPAs) and Client-Side Rendering (CSR). Now, the pendulum has swung back towards the server, but with a modern twist.

Understanding how, when, and where your application turns data into HTML is one of the most critical architectural decisions you will make. This guide breaks down Server-Side Rendering (SSR) and how it compares to CSR, Static Site Generation (SSG), and Incremental Static Regeneration (ISR).

Client-Side Rendering (CSR)

In Client-Side Rendering, the server responds to a navigation request with a barebones HTML document. It typically looks something like this:

<!DOCTYPE html>
<html>
  <head>
    <script src="/bundle.js" defer></script>
  </head>
  <body>
    <div id="root"></div>
  </body>
</html>

The browser must download, parse, and execute the massive bundle.js file before it can fetch data from an API and eventually manipulate the DOM to show the user the application.

Pros of CSR:

Rich Interactions: Once loaded, subsequent navigation is instantaneous because the app behaves like a desktop application.
Cheap Hosting: You only need to serve static files (HTML, JS, CSS) which can be thrown on an S3 bucket or cheap CDN.
Decoupling: The front-end is completely decoupled from the back-end API.

Cons of CSR:

Poor SEO: While Googlebot can execute JavaScript, many other crawlers cannot, leading to poor indexing.
Slow Initial Load: Users stare at a blank white screen while the JavaScript bundle downloads and executes.
Client Performance Dependency: The speed of your app depends heavily on the user's device CPU and network speed.

Server-Side Rendering (SSR)

Server-Side Rendering fixes the "blank white screen" problem. When a user requests a page, a server (like Node.js) fetches the necessary data, renders the React/Vue/Svelte components into HTML, and sends a fully formed HTML document to the browser.

The user immediately sees the content. Then, the browser downloads the JavaScript bundle and "hydrates" the static HTML, attaching event listeners and making it interactive.

Pros of SSR:

Excellent SEO: Every crawler sees the fully populated HTML immediately.
Fast First Contentful Paint (FCP): Users see content much faster than with CSR.
Social Sharing: Open Graph tags can be populated dynamically based on the requested URL.

Cons of SSR:

TTFB (Time to First Byte): The server must fetch data and render HTML on every request, delaying the initial response.
Server Costs: You need a running Node.js server (or serverless functions) to compute the HTML, which is more expensive than static hosting.
Complexity: You must write code that can run in both Node.js and the browser (Isomorphic JavaScript).

Static Site Generation (SSG)

Static Site Generation takes the benefits of SSR but shifts the computation to build time instead of request time. Frameworks like Astro, Next.js, and Gatsby fetch data and generate static HTML files during the CI/CD pipeline.

Pros of SSG:

Ultimate Performance: HTML files are pre-built and served directly from a global CDN. TTFB is blazing fast.
High Security: No database or server is exposed during runtime.
Cheap & Scalable: Serving static files requires minimal infrastructure.

Cons of SSG:

Stale Data: Content cannot change without a full site rebuild.
Build Times: If you have 100,000 pages (e.g., an e-commerce store), rebuilding the entire site on every product update can take hours.

Incremental Static Regeneration (ISR)

ISR is a hybrid approach pioneered by Next.js to solve the slow build times of SSG. It allows you to use static generation on a per-page basis, without needing to rebuild the entire site.

With ISR, you define a revalidation time (e.g., 60 seconds). When a user requests a page, they get the cached static HTML. If 60 seconds have passed, the next user still gets the stale HTML, but the server triggers a background rebuild of that specific page. Once the rebuild is done, the cache is invalidated, and subsequent users get the fresh content.

Pros of ISR:

Best of Both Worlds: The speed of SSG with the freshness of SSR.
Fast Build Times: You can choose to generate only the most critical pages at build time and generate the rest on-demand.

Cons of ISR:

Vendor Lock-in: ISR is highly dependent on specific hosting infrastructure (like Vercel) to manage the caching and background regeneration correctly.

Summary: Which should you choose?

CSR: Dashboards, internal tools, highly interactive web apps where SEO doesn't matter.
SSR: Dynamic applications where content changes frequently and SEO is critical (e.g., Twitter, dynamic e-commerce).
SSG: Blogs, marketing sites, documentation (e.g., this exact website).
ISR: Large content sites or e-commerce stores with millions of pages where SSG build times are too slow.