Stop 17 · System Design for Full-Stack AppsTopics · 2/7

Choosing a Rendering Strategy (CSR/SSR/SSG)

Part of the Full Stack Developer Roadmap

In short

Your blog, your product page and your dashboard should not all render the same way. Picking per page decides how fast it opens, how Google sees it and how fresh the data is.

Deciding, per page, whether to render client-side, server-side per request, or statically at build time — a decision with real consequences for SEO, performance, and data freshness.

The purple blob makes a dosa between a row of ready thalis and a bag of raw vegetables.

Think of it like this

Ready plates, dosa or meal kit

A restaurant plates the fixed lunch before the rush: instant, same for all (SSG). Dosa is made when you order: fresh, but you wait a bit (SSR). A meal kit sends raw ingredients and you cook at home (CSR). Good kitchens do all three.

Watch it happen

Picking a strategy, page by page

Pick per page

Same for all

Fresh every hit

Rarely changes

Changes hourly

SSG

ISR

Public + SEO

Logged-in only

SSR

CSR

1/5Ask the question for each page, not for the whole app.

The big ideas

What you need to know

SSG: built at deploy time

HTML is made once during the build and served from a CDN. Fastest and cheapest, but data is as old as the last build.

ISR: static with a timer

Static pages that rebuild in the background after a set time, so they stay fast and reasonably fresh.

SSR: rendered per request

The server builds HTML on each visit. Always fresh and SEO-friendly, but every visit costs server time.

CSR: the browser builds it

The server sends a light shell and JavaScript fetches the data. Great behind login, poor for SEO and first paint.

See it in code

Walk through the code

tsx

1// app/blog/[slug]/page.tsx: SSG, every post built at deploy time2export async function generateStaticParams() {3  const posts = await getAllPosts();4  return posts.map((p) => ({ slug: p.slug }));5}6 7// app/products/page.tsx: ISR, rebuilt in the background at most once an hour8export const revalidate = 3600;9 10// app/search/page.tsx: SSR, rendered fresh for every request11export const dynamic = "force-dynamic";12 13// app/dashboard/chart.tsx: CSR, this component runs in the browser14"use client";

1/4generateStaticParams lists every slug at build time, so each post becomes a static HTML file.

In the Next.js App Router, each file picks its own strategy with one or two lines. Four files, four strategies, one app.

Save yourself the pain

Common mistakes

Oops

Making the whole app CSR, so Google and WhatsApp previews see an empty page.

Do this instead

Render public, shareable pages with SSG, ISR or SSR. Keep CSR for screens behind login.

Oops

Using SSR for a page that is the same for everyone, then wondering why the server bill grew.

Do this instead

If the page doesn't depend on the request, make it static or ISR and let the CDN serve it.

Your mission

One app, four strategies

~40 min

Quick check

A news site's article page should load fast, rank on Google and show edits within a few minutes. Best fit?

Go deeper

1Categorize a few pages of a project by which rendering strategy fits best.
2Learn why a marketing page favors SSG/SSR (SEO) while a dashboard favors CSR (interactivity).
3Understand ISR as a middle ground combining SSG's speed with periodic freshness.