CSR, SSR, and SSG

Build the mental model

Every web page needs HTML before a browser can show anything. The real design question behind CSR, SSR, and SSG is simple to state but has real consequences: where and when is that HTML actually generated?

Is it built in the browser after JavaScript runs, built on a server for each request, or built once ahead of time during a build step? Each answer creates a different rendering strategy with its own strengths.

Client-Side Rendering (CSR) sends the browser a mostly empty HTML shell plus JavaScript files. The browser downloads that JavaScript, runs it, fetches any data it needs, and then builds the visible page entirely on the client.

CSR suits highly interactive interfaces well: once the app loads, moving between views can feel instant with no full page reloads. But the initial load has more work to do, the page depends on JavaScript running successfully, and search engines or slow devices sometimes need extra care to see the finished content.

Server-Side Rendering (SSR) flips the order: the server builds the actual HTML for each request and sends a ready-to-display page to the browser, which JavaScript may then hydrate to attach interactivity.

SSR usually shows content faster on first load and can reflect dynamic, per-request data immediately, at the cost of more server work per request and some added caching complexity.

Static Site Generation (SSG) generates HTML once, ahead of time, during a build step, then serves those static files from a CDN. It fits content that does not change per visitor, like documentation, blogs, and marketing pages, though dynamic behavior can still be layered on top in the browser.

CSR

Client-Side Rendering — the browser downloads JavaScript and builds the visible page in the client after the app loads.

SSR

Server-Side Rendering — the server builds HTML for each request and sends a ready-to-display page to the browser.

SSG

Static Site Generation — HTML is generated once ahead of time during a build step and served as static files.

CSR, SSR, AND SSG: WHERE HTML IS BUILT
--------------------------------------
CSR, SSR, AND SSG: WHERE HTML IS BUILT
---------------------------------------
CSR (Client-Side Rendering)
  Browser gets shell + JS files
       |
       v
  JavaScript runs in browser
       |
       v
  Browser fetches data
       |
       v
  UI rendered on the client

SSR (Server-Side Rendering)
  Browser sends request
       |
       v
  Server renders HTML per request
       |
       v
  HTML response sent to browser
       |
       v
  JavaScript may hydrate the page

SSG (Static Site Generation)
  Build time: HTML generated once
       |
       v
  Static files pushed to a CDN
       |
       v
  User requests the page
       |
       v
  CDN serves the pre-built HTML

Connect it to a real scenario

Think about picking a rendering strategy the way you would think about picking a foundation for a building. Start by asking what the page actually needs, not which technology is trendy right now.

• Does this page need to rank well in search results the moment it is published, or is it behind a login where crawlers never visit?
• Does it show data that changes every second, once a day, or basically never after publishing?
• Does every visitor see the same content, or is it personalized per user?

A marketing homepage that rarely changes is a strong candidate for SSG: build it once, serve it from a CDN, and it stays fast under heavy traffic.

A dashboard showing live account data per logged-in user usually leans SSR or CSR, because the content depends on who is asking and needs to be fresh.

A highly interactive tool like a design editor or spreadsheet often leans CSR, because the interactivity after load matters more than the very first paint.

None of these are permanent rules, they are starting points you revisit as requirements change.

• CSR, SSR, and SSG each answer the same question — where and when is HTML generated — differently.
• CSR favors interactivity after load; SSR favors fast, fresh first content; SSG favors speed and low cost for unchanging content.
• The right strategy for a page is a starting-point decision based on its actual requirements, not a fixed rule.

Try the working example

function recommendRenderingStrategy({ needsSEO, needsRealtimeData, contentChangesPerUser, updateFrequency }) {
  const isFrequentlyDynamic =
    needsRealtimeData || updateFrequency === "seconds" || updateFrequency === "minutes";

  if (contentChangesPerUser || isFrequentlyDynamic) {
    // Content differs per visitor or changes very often: a build-time
    // snapshot can't capture it, so pick based on whether search engines
    // need to see the fully rendered content immediately.
    return needsSEO ? "SSR" : "CSR";
  }

  // Same content for every visitor, and it doesn't change constantly.
  return "SSG";
}

const pages = [
  {
    name: "Marketing homepage",
    needsSEO: true,
    needsRealtimeData: false,
    contentChangesPerUser: false,
    updateFrequency: "never",
  },
  {
    name: "Logged-in user dashboard",
    needsSEO: false,
    needsRealtimeData: true,
    contentChangesPerUser: true,
    updateFrequency: "seconds",
  },
  {
    name: "Live sports scores page",
    needsSEO: true,
    needsRealtimeData: true,
    contentChangesPerUser: false,
    updateFrequency: "seconds",
  },
];

for (const page of pages) {
  const recommendation = recommendRenderingStrategy(page);
  console.log(`${page.name}: ${recommendation} (starting point, not an absolute rule)`);
}

Running this prints a per-page recommendation: Marketing homepage -> SSG, Logged-in user dashboard -> CSR, Live sports scores page -> SSR — each labeled as a starting point, not an absolute rule.

web.dev — Rendering on the Web — How the Web Works