Welcome to my personal blog

Server-Side Rendering vs Client-Side Rendering Explained

Published on
4 min read
← Back to the blog
Authors

If you're building modern web applications with React or NextJS, you've probably heard the terms "Server-Side Rendering" (SSR) and "Client-Side Rendering" (CSR) thrown around. But what do they actually mean, and more importantly, which one should you use?

What is Client-Side Rendering (CSR)?

Client-Side Rendering is the traditional approach used by most React applications. Here's how it works:

  1. The server sends a minimal HTML file to the browser
  2. The browser downloads the JavaScript bundle
  3. JavaScript executes and builds the entire page in the browser
  4. The user finally sees the content

Think of it like ordering furniture from IKEA. You get a flat pack (minimal HTML), and you have to assemble it yourself (JavaScript builds the page) before you can use it.

Example CSR Flow

// Traditional React app (CSR)
import React, { useState, useEffect } from 'react';

function BlogPost() {
  const [post, setPost] = useState(null);
  
  useEffect(() => {
    // Data fetching happens in the browser
    fetch('/api/posts/1')
      .then(res => res.json())
      .then(data => setPost(data));
  }, []);
  
  if (!post) return <div>Loading...</div>;
  
  return (
    <article>
      <h1>{post.title}</h1>
      <p>{post.content}</p>
    </article>
  );
}

What is Server-Side Rendering (SSR)?

Server-Side Rendering means the HTML is generated on the server for each request. The user receives a fully-rendered page immediately.

  1. User requests a page
  2. Server fetches data and generates complete HTML
  3. Browser receives ready-to-display HTML
  4. JavaScript "hydrates" the page to make it interactive

This is like ordering pre-assembled furniture. It arrives ready to use immediately.

Example SSR Flow

// NextJS page with SSR
export default function BlogPost({ post }) {
  return (
    <article>
      <h1>{post.title}</h1>
      <p>{post.content}</p>
    </article>
  );
}

// This runs on the server for each request
export async function getServerSideProps({ params }) {
  const res = await fetch(`https://api.example.com/posts/${params.id}`);
  const post = await res.json();
  
  return {
    props: { post }
  };
}

Key Differences

Performance

CSR: Slow initial load (needs to download and execute JavaScript), but fast navigation between pages once loaded.

SSR: Fast initial load (HTML is ready), but each page navigation requires a server round-trip.

SEO

CSR: Challenging for SEO. Search engines may struggle to index JavaScript-heavy content.

SSR: Excellent for SEO. Search engines receive fully-rendered HTML with all content visible.

Server Load

CSR: Minimal server load. The server just serves static files.

SSR: Higher server load. The server must render HTML for every request.

User Experience

CSR: Users see a blank page or loading spinner initially. Content appears after JavaScript loads.

SSR: Users see content immediately, even before JavaScript loads. Better perceived performance.

When to Use Each

Use Client-Side Rendering When:

  • Building a dashboard or admin panel (SEO doesn't matter)
  • Creating a web application with authentication
  • You need highly interactive features
  • Your users have reliable, fast internet connections
  • Server costs are a concern

Use Server-Side Rendering When:

  • SEO is critical (blogs, e-commerce, marketing sites)
  • You need fast initial page loads
  • Your content changes frequently
  • Users may have slow connections
  • Accessibility is a priority

The Best of Both Worlds: Static Site Generation (SSG)

NextJS offers a third option: Static Site Generation. Pages are pre-rendered at build time, giving you SSR benefits without the server overhead.

// NextJS page with SSG
export default function BlogPost({ post }) {
  return (
    <article>
      <h1>{post.title}</h1>
      <p>{post.content}</p>
    </article>
  );
}

// This runs at build time
export async function getStaticProps({ params }) {
  const res = await fetch(`https://api.example.com/posts/${params.id}`);
  const post = await res.json();
  
  return {
    props: { post },
    revalidate: 60 // Regenerate page every 60 seconds
  };
}

For a blog like yours, SSG is often the perfect choice. You get the SEO and performance benefits of SSR, but your pages are served as static files.

Conclusion

There's no one-size-fits-all answer. Modern frameworks like NextJS let you mix and match these approaches:

  • Use SSG for your blog posts
  • Use SSR for dynamic pages that need fresh data
  • Use CSR for interactive components within those pages

Understanding these rendering strategies helps you make informed decisions and build better web applications. As you continue learning React and NextJS, experiment with each approach to see what works best for your projects.

Resources

Comments