DEV Community

Cover image for CSR vs SSG vs SSR: What They Mean and How React & Next.js Use Them
Farhad Faraji
Farhad Faraji

Posted on

CSR vs SSG vs SSR: What They Mean and How React & Next.js Use Them

#webdev #react #nextjs #javascript

Hey there! If you're new to web development, you might have heard buzzwords like CSR, SSG, and SSR thrown around. They sound technical, but don’t worry, I’m going to break them down as if we’re having a chat with the browser, HTML, and JavaScript. Think of it like a friendly conversation where each part of the web explains its role. Let’s dive in and make sense of why people say “Next.js is great for SEO” with simple examples using React and Next.js.

The Beginning: Plain HTML (The Browser’s Story)

Browser: Hey, I’m the browser, Chrome, Firefox, or whatever you’re using. When someone visits a webpage, they send me an HTTP request, and I grab an HTML file from a server. My job is simple:

  • I parse the HTML to build the structure of the page.
  • If there’s CSS, I use it to make things pretty.
  • If there’s JavaScript, I run it to add interactivity.

HTML: I’m the backbone! For a basic webpage, I’m just a static file with some tags. Like this:

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>Basic Page</title>
  </head>
  <body>
    <h1>Welcome to my page!</h1>
    <p>I’m just static content, ready to go.</p>
  </body>
</html>
Enter fullscreen mode Exit fullscreen mode

Browser: When I get this HTML, I display it instantly. No fuss, no waiting. Search engines like Google love me because I’m straightforward, and they can read my content right away. But if you want a fancier, interactive page, I need some help from JavaScript.

Enter React: Client-Side Rendering (CSR) (JavaScript Takes the Stage)

JavaScript: Hey, I’m JavaScript, and I make things dynamic! With React, I can build complex, interactive UIs that update without reloading the whole page. But here’s how it works in a Client-Side Rendering (CSR) setup:

HTML: In a React app, I’m super minimal at first. I might look like this:

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>React CSR Example</title>
  </head>
  <body>
    <div id="root"></div>
    <script src="main.js"></script>
  </body>
</html>
Enter fullscreen mode Exit fullscreen mode

Browser: When I get this HTML, it’s basically empty, just a <div id="root">. I’m like, “Uh, where’s the content?” I have to wait for JavaScript to load and run.

JavaScript: That’s where I come in! I use React to fill that empty root div with awesome content. Check this out:

// main.js
import React from "react";
import ReactDOM from "react-dom/client";

function App() {
  return <h1>Hello from React CSR!</h1>;
}

const root = ReactDOM.createRoot(document.getElementById("root"));
root.render(<App />);
Enter fullscreen mode Exit fullscreen mode

Browser: Once JavaScript runs, I finally see the <h1>Hello from React CSR!</h1> and display it. It’s cool, but there’s a catch…

Search Engine Crawler: Hey, I’m Google’s crawler. I visit pages to index them for search results. When I see that empty <div id="root">, I might not wait for JavaScript to load. So, I could miss the content, which is bad for SEO.

JavaScript: Yeah, that’s the downside of CSR. I’m great for interactive apps, but search engines might not see the full page right away because I do all the rendering in the browser.

Next.js and Pre-Rendering (The Server Steps In)

Server: Hey, I’m the server, and Next.js is my buddy. Unlike plain React, I can pre-render HTML before sending it to the browser. That means the browser and search engines get a fully loaded page from the start.

Browser: Oh, nice! So when I get a page from Next.js, it’s already filled with content? No waiting for JavaScript?

Server: Exactly! With Next.js’s App Router, I render the JSX on the server and send a complete HTML document. Search engines love this because they see the content immediately.

Search Engine Crawler: Yup, I can index that pre-rendered HTML right away. That’s why people say Next.js is SEO-friendly; it’s like serving me a ready-to-read page.

Static Site Generation (SSG) (The Pre-Baked Cake)

Server: Let’s say you have a page with content that doesn’t change often, like a blog homepage or a marketing page. With Static Site Generation (SSG), I generate the HTML at build time, like baking a cake before the party starts.

Browser: So, when I request the page, you just hand me that pre-baked HTML?

Server: Yup, it’s super fast because the work’s already done. Here’s an example in Next.js:

// app/page.js
export default function Home() {
  return <h1>Hello from Next.js SSG!</h1>;
}
Enter fullscreen mode Exit fullscreen mode

Server: I build this HTML once during the build process, and then I serve it to every user who visits. It’s lightning-fast and great for static content.

Search Engine Crawler: Love it! I get the full HTML right away, so indexing is a breeze.

JavaScript: Do I even need to do anything here?

Server: Not much! The browser can still run JavaScript for interactivity, but the heavy lifting is done by me at build time.

Server-Side Rendering (SSR) (Fresh Content Every Time)

Server: Now, what if your data changes often? Like a list of celebrities that updates every hour? That’s where Server-Side Rendering (SSR) comes in. I fetch the latest data for every request, generate fresh HTML, and send it to the browser.

Browser: So, I get a new, fully rendered page every time?

Server: Exactly. Here’s how it looks in Next.js:

// app/celebrities/page.js
async function getCelebrities() {
  const res = await fetch("https://api.example.com/celebrities", {
    cache: "no-store", // ensures fresh data on every request
  });
  return res.json();
}

export default async function CelebritiesPage() {
  const celebrities = await getCelebrities();

  return (
    <div>
      <h1>Celebrity List</h1>
      <ul>
        {celebrities.map((c) => (
          <li key={c.id}>{c.name}</li>
        ))}
      </ul>
    </div>
  );
}
Enter fullscreen mode Exit fullscreen mode

Server: For every request, I call getCelebrities(), build the HTML with the latest data, and send it to the browser. It’s fresh every time.

Search Engine Crawler: Perfect! I always see the latest content, so I can index it accurately.

Browser: And I display it instantly without waiting for JavaScript to fill in the blanks.

JavaScript: I can still add interactivity after the page loads, right?

Server: Yup, you can take over for things like button clicks or dynamic updates, but I handle the initial render.

Quick Recap (Everyone Chimes In)

Browser: So, let’s sum it up:

  • CSR (React default): I get an empty HTML with a <div id="root">. JavaScript does all the work in the browser, but it’s not great for SEO because crawlers might miss the content.
  • SSG (Next.js): I get pre-baked HTML from the server at build time. It’s super fast and great for static stuff like blogs.
  • SSR (Next.js): I get fresh HTML from the server for every request, perfect for dynamic content like live data.

Search Engine Crawler: Next.js is my favorite because it gives me pre-rendered HTML, whether it’s SSG or SSR. I can index it easily, which makes Next.js awesome for SEO.

JavaScript: And I still get to shine in Next.js for interactivity, even if the server does the heavy lifting for rendering.

🚀 You: Now that you’ve heard from the browser, HTML, JavaScript, and the server, you should have a clear picture of when to use CSR, SSG, or SSR, and why Next.js is a powerhouse for building modern, SEO-friendly websites.

Top comments (0)