Exercise: The Rendering Strategy Lab

Build the mental model

This lesson is a practice exercise, not new theory. It asks you to apply CSR, SSR, SSG, and hybrid rendering from the Advanced chapter to four realistic pages: a marketing homepage, a user dashboard, a blog, and a live chat feature.

Every decision comes down to the same four questions -- there is no fifth hidden factor, and it's the combination of answers that points toward a strategy, not any single one alone.

Does this page need to rank well in search engines (SEO)?
Does its content differ from one visitor to the next (personalization)?
Does it need data that updates in real time?
How often does the underlying content actually change?

No universal winner

A dashboard and a marketing page can share one application and reasonably use two different rendering strategies -- because requirements differ, never because one strategy is objectively superior.

text

RENDERING STRATEGY LAB - ANSWER KEY
-----------------------------------
Marketing homepage   (SEO, stable content)        --> SSG
User dashboard       (per-user, private data)     --> SSR
Blog                 (SEO, updates often)          --> Hybrid (SSG + ISR)
Live chat            (needs realtime data)         --> CSR + live connection

Connect it to a real scenario

Here is one way to reason through each page, offered as a worked answer key rather than the only acceptable answer -- compare it with your own notes rather than just copying it.

Page	Recommended strategy & reason
Marketing homepage	SSG -- public, SEO-sensitive, and stable enough to pre-render once at build time.
User dashboard	SSR (or CSR behind auth) -- content is personalized per visitor, so it cannot be pre-built once for everyone.
Blog	Hybrid (SSG + scheduled or on-demand revalidation) -- needs SEO, but new posts appear too often for a one-time build to stay accurate.
Live chat	CSR with a persistent live connection (often inside an SSR/SSG page shell) -- no pre-rendering approach can keep a live feed current.

Notice the pattern: real-time data always wins first, personalization rules out static generation next, and only pages with neither of those get to weigh SEO against update frequency to choose between SSG and a hybrid approach.

The same four questions -- SEO need, per-user content, real-time data, and update frequency -- drive every rendering-strategy decision, no matter the page.
Different pages inside one application can reasonably use different rendering strategies; there's no single right answer for an entire site.
A worked answer key is a starting point for your own reasoning, not proof every real project must land on the same choice.

Try the working example

javascript

function recommendRenderingStrategy(page) {
  const { name, needsSEO, changesPerUser, needsRealtimeData, updateFrequency } = page;

  if (needsRealtimeData) {
    return {
      name,
      strategy: "CSR (or hybrid shell + live connection)",
      reason: "Needs live, second-by-second data that no pre-rendered page can stay fresh for."
    };
  }

  if (changesPerUser) {
    return {
      name,
      strategy: "SSR (or CSR behind auth)",
      reason: "Content is personalized per visitor, so it cannot be pre-built once for everyone."
    };
  }

  if (needsSEO && updateFrequency === "rarely") {
    return {
      name,
      strategy: "SSG",
      reason: "Public and SEO-sensitive, but stable enough to pre-render at build time."
    };
  }

  if (needsSEO && updateFrequency !== "rarely") {
    return {
      name,
      strategy: "Hybrid (SSG + incremental revalidation) or SSR",
      reason: "Needs SEO, but content changes too often for a one-time build to stay accurate."
    };
  }

  return {
    name,
    strategy: "CSR",
    reason: "No SEO requirement and nothing personalized, so client-side rendering is simplest."
  };
}

const pages = [
  {
    name: "Marketing homepage",
    needsSEO: true,
    changesPerUser: false,
    needsRealtimeData: false,
    updateFrequency: "rarely"
  },
  {
    name: "User dashboard",
    needsSEO: false,
    changesPerUser: true,
    needsRealtimeData: false,
    updateFrequency: "often"
  },
  {
    name: "Blog",
    needsSEO: true,
    changesPerUser: false,
    needsRealtimeData: false,
    updateFrequency: "occasionally"
  },
  {
    name: "Live chat",
    needsSEO: false,
    changesPerUser: true,
    needsRealtimeData: true,
    updateFrequency: "constantly"
  }
];

for (const page of pages) {
  const result = recommendRenderingStrategy(page);
  console.log(`${result.name} -> ${result.strategy}\n  reason: ${result.reason}`);
}

You should see

Marketing homepage -> SSG
  reason: Public and SEO-sensitive, but stable enough to pre-render at build time.
User dashboard -> SSR (or CSR behind auth)
  reason: Content is personalized per visitor, so it cannot be pre-built once for everyone.
Blog -> Hybrid (SSG + incremental revalidation) or SSR
  reason: Needs SEO, but content changes too often for a one-time build to stay accurate.
Live chat -> CSR (or hybrid shell + live connection)
  reason: Needs live, second-by-second data that no pre-rendered page can stay fresh for.

5-minute try-it

Before reading the worked answer key in the practical section, decide for yourself which rendering strategy -- CSR, SSR, SSG, or a hybrid approach -- best fits each of these four pages, and write down your reasoning:

1. A marketing homepage for a small business, with a handful of pages that rarely change.
2. A user dashboard behind a login screen, showing each visitor their own personalized data.
3. A blog with a public archive of articles, where new posts are published every week or two.
4. A live chat feature where messages need to appear the instant they are sent.

For each page, work through the same four questions: does it need to rank in search engines, does its content differ per visitor, does it need real-time data, and how often does its content actually change? Only check the practical section's answer key after you've written down your own answer and reasoning for all four.

One important caution

Picking a rendering strategy because it's trendy, instead of matching it to this page's actual SEO, personalization, and freshness needs.

Assuming an entire application must use one rendering strategy everywhere, when mixing CSR, SSR, SSG, and hybrid page-by-page is normal and often the better fit.

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