SSR vs CSR vs SSG: Choosing How Your Pages Get Rendered

Modern frameworks let you render pages in several different ways, often within the same app. The acronyms (SSR, CSR, SSG, ISR) sound like jargon, but the choice has a real effect on load speed, SEO, hosting cost and how fresh your data is. Here's what each one means and when to use it.

Client-side rendering (CSR)

The server sends a mostly empty HTML page plus a JavaScript bundle. The browser downloads and runs the JavaScript, which fetches data and builds the page.

• Pros: simple hosting (static files), rich interactivity, fast navigation between views once loaded.
• Cons: slower first meaningful paint, especially on slow phones; content isn't in the initial HTML, which can hurt SEO and link previews; large bundles hurt responsiveness.

Good for: dashboards and tools behind a login, where SEO doesn't matter and users stay a while.

Server-side rendering (SSR)

The server builds the full HTML for each request, with data already in it, and sends it to the browser. JavaScript then hydrates the page, attaching event handlers to make it interactive.

• Pros: content is visible quickly and present in the HTML for search engines and social previews; always fresh data; can personalise per user.
• Cons: server work on every request (cost and latency); slow data sources delay the whole page unless you stream; hydration still requires shipping JavaScript.

Good for: pages that are personalised or change constantly and still need fast first loads and SEO, like search results, feeds and product pages with live stock.

Static site generation (SSG)

Pages are rendered to HTML at build time, then served as static files from a CDN.

• Pros: extremely fast, cheap to host, very reliable, great for SEO.
• Cons: content is only as fresh as the last build; building thousands of pages can take a while.

Good for: blogs, documentation, marketing pages, portfolios: anything that changes occasionally.

Incremental regeneration (ISR) and revalidation

A middle ground: serve a static page, but regenerate it in the background after a set time, or on demand when content changes. Users get static-file speed with content that's at most a few minutes old.

Good for: blogs with a CMS, product catalogues, any public content that changes regularly but not every second. (How this relates to caching.)

Hydration, streaming and islands

• Hydration is the step where JavaScript takes over server-rendered HTML. Until it finishes, buttons may not respond. Heavy hydration is a common cause of poor interaction responsiveness.
• Streaming sends HTML in chunks as data becomes ready, so a slow widget doesn't hold back the whole page.
• Server Components and islands architecture reduce how much JavaScript ships by rendering non-interactive parts on the server only and hydrating just the interactive pieces.

Comparison

	CSR	SSR	SSG	ISR
First load speed	Slower	Fast	Fastest	Fastest
Data freshness	Live	Live	At build time	Periodic / on demand
SEO friendliness	Weaker	Strong	Strong	Strong
Server cost	Lowest	Highest	Lowest	Low
Personalisation	Yes (client)	Yes	No (or client-side)	No (or client-side)

Choose per page, not per app

Frameworks like Next.js, Nuxt, SvelteKit, Astro and Remix-style frameworks let different routes use different strategies. A typical setup:

• Homepage, blog, docs: SSG or ISR
• Product and category pages: ISR, or SSR if stock and prices change constantly
• Search results: SSR
• Logged-in dashboard: SSR for the shell, client-side updates within it, or plain CSR
• Checkout: SSR or CSR with careful loading states

Questions that decide it

1. Does this page need to rank in search or show rich link previews? Avoid pure CSR.
2. Is the content the same for everyone? Static (SSG/ISR) is usually best.
3. How fresh must it be? Seconds: SSR. Minutes: ISR. Days: SSG.
4. Is it personalised? SSR, or static shell plus client-side data.
5. What does it cost to render? Expensive pages benefit from caching or static generation.

Common mistakes

• Making an entire public site client-rendered, then fighting SEO problems. (Technical SEO.)
• Using SSR for pages that never change, paying server costs for no benefit.
• Hiding server-rendered content behind animations that start invisible, which delays when the browser counts it as painted. (Diagnosing slow pages.)
• Shipping huge client bundles to hydrate mostly static content.

FAQ

What is the difference between SSR and SSG?

SSR renders HTML on the server for each request, so content is always fresh. SSG renders HTML once at build time and serves static files, which is faster and cheaper but only as fresh as the last build.

Is client-side rendering bad for SEO?

Search engines can render JavaScript, but it's slower and less reliable than serving complete HTML, and many link-preview bots don't run JavaScript. Public pages generally do better with SSR or static generation.

What is hydration?

The process where JavaScript running in the browser attaches event handlers and state to server-rendered HTML, making the page interactive.