Choosing a Rendering Method — CSR / SSR / SSG / ISR

About this article

This article is the second deep dive in the “Frontend Architecture” category of the Architecture Crash Course for the Generative-AI Era series, covering rendering methods.

The decision “when and where to generate the HTML” — modern options diversify across browser, server, build time, and CDN edge. The article covers the four methods (CSR, SSR, SSG, ISR), modern technologies (Hydration, Islands, Streaming SSR, RSC), and “per-page method selection” as the modern default.

What is a rendering method in the first place

A rendering method is, roughly speaking, “the choice of when and where to assemble the content (HTML) of a web page.”

A cooking analogy might help. Cook to order in the kitchen (SSR), prepare in advance and just serve from the shelf (SSG), send only ingredients and let the customer finish at the table (CSR) — each differs in serving speed, freshness, and effort. Web pages are the same: the timing and place of assembly changes the balance of display speed, SEO, and server cost.

The modern standard is per-page method selection. One site need not mean one method.

Why rendering method selection matters

If you build every page the same way without thinking about rendering methods, something will always break. All-SSR explodes server costs, and all-CSR kills SEO. Reverse-engineering from business requirements to decide what fits each page is where frontend design skill shows.

Projects with wrong method choices have real accidents — server costs spiking on campaign day one forcing rewrites, or zero Google visibility killing acquisition. Just deciding “which page, which method” upfront prevents most of these.

The quick version of the decision runs like this.

Before diving into details, here are typical site types and their first-choice methods. Use this to get your bearings, then check each method’s details.

The four main methods

Selection ties directly to performance, SEO, and ops cost. All-page SSR explodes server cost; all-page CSR crashes SEO. Reasoning back from business requirements about which method fits which page is the showcase of frontend design skill.

The modern default: per-page method selection. No need for one site = one method.

A faster way to decide is this.

Before details, the first candidate per typical site type. Anchor here, then check details per method.

CSR — for admin screens where SEO does not matter and interaction does

CSR sends “empty HTML and JS” to the browser; the browser executes JavaScript to build the DOM. The basic SPA (Single Page Application) form — naive React / Vue use is essentially this.

Page transitions don’t full-load — partial updates make interaction extremely fast once loaded. But initial load downloads all JS, then runs, then fetches APIs to render — initial display tends to be slow. Empty HTML means Google’s crawler doesn’t see content, decisively weak on SEO.

Admin / dashboards / login-after apps — uses prioritizing operability without SEO are optimal.

SSR — SEO and interactivity together

SSR generates HTML on the server per request and returns it. Same in essence as classical PHP / Rails / Django, but modern SSR renders React / Vue components server-side.

[Browser] ──(request)──→ [Server]
                          React/Vue generates HTML
     ←────(complete HTML)────    + Hydration JS

Browsers receive complete HTML, so initial display is fast and SEO is strong. Per-request server processing increases load and cost over static delivery substantially. High-traffic sites combine with CDN caching.

The default mode of Next.js / Nuxt / Remix. The favorite when SEO and interactivity are both required.

SSG — fastest, cheapest, most failure-resistant

SSG pre-generates all pages at build time as static files; CDN just delivers afterward. Zero server processing at request time, so fastest, cheapest, most outage-resilient delivery.

[CI/CD build]
  All URLs → HTML generation
  ↓
[CDN delivery]  ← pre-generated

Astro, Hugo, Jekyll, Eleventy are typical; shines on content-centric sites (blogs, docs, marketing). Downside: build time. Past several thousand pages, builds can take tens of minutes. “Re-build whole site on every update” also makes it weak for frequent updates.

For blogs, docs, LPs, SSG is optimal. This series’s host senkohome.com also runs on Astro SSG.

ISR — the best of SSG and SSR

ISR is the good-of-both hybrid between SSG and SSR. Pre-generates main pages at build, then re-generates in the background after a period. Users always get cache-served HTML immediately while data freshness is maintained.

1. Build: pre-generate main pages
2. Access: serve cache if within window
3. Window expired: regenerate in background
4. Next access shows new version (stale-while-revalidate)

Next.js originated this, solving SSG’s “rebuild everything on every update” problem. E-commerce product pages (price and inventory change often, basics fixed) and news article pages — “semi-static, semi-dynamic content” is optimal.

A breakthrough method solving SSG’s weakness directly. Optimal for many-page sites with some frequent updates.

Modern techniques — Hydration, Islands, Streaming and RSC

Hydration adds interactivity via JavaScript to HTML generated by SSR or SSG. After the browser receives “static HTML” generated server-side, JS mounts and event listeners register — only then do button clicks and other interactions function.

[SSR HTML] → display in browser (not yet interactive)
   ↓
[Load and run JS] → Hydration (events activated)
   ↓
[Interactive]

The problem: re-running all the page’s JS is costly. The solution: Islands Architecture — a paradigm shift where “only interactive parts ship JS.” Astro is the canonical example, keeping 99% of pages as static HTML and running only interactive parts (cart, etc.) as small JS islands.

Astro’s Islands is the modern optimum, dramatically reducing JS shipping and reconciling LCP and INP.

Streaming SSR is the next step from there.

Streaming SSR is the new method that streams to the browser as parts become ready rather than returning all HTML at once. Modern React / Next.js App Router / Remix support it as standard, solving “a slow API blocks the whole page.”

<html>
  <head>...</head>
  <body>
    <Header />          ← sent immediately
    <MainContent />     ← sent immediately
    <Suspense>          ← deferred with fallback UI
      <SlowData />      ← streamed in after data arrives
    </Suspense>
  </body>

In traditional SSR, even one slow API made all HTML wait, so “the slowest part decides whole-page speed.” With Streaming, the skeleton returns first and slow parts show loading UI — TTFB (Time To First Byte) improves dramatically.

React Server Components take the same idea further.

RSC (React Server Components) is a new paradigm running React components on the server. Traditional React all ran in the browser; RSC runs server-side and ships only the result.

RSC’s biggest value is JS-bundle reduction. Components for data fetching and shaping — “display only” — run server-side, shipping only the resulting HTML; only interactive parts ship JS, reducing what users download substantially.

The default of Next.js App Router. The fundamental answer to the JS-bundle problem.

How to choose — a page-type × method ladder

The five methods compare as follows.

Lining up the four rendering methods reveals each one’s strong area. “None is omnipotent,” so picking and combining per business need is modern.

SSG is weak on “build time and dynamic updates”; SSR is weak on “cost and outage resilience” — each method has clear trade-offs. ISR balances these well, but at the cost of complex internals raising the comprehension bar.

By case, the choice lands like this.

Choose rendering methods at the use-case granularity. Mixing methods per page within one site is modern design.

Note: industry rates as of April 2026. Periodic refresh required.

“One site = one method” breaks down; explicitly sort method by page nature — modern default.

ISR revalidate is 60-600 seconds as standard. Shorter dilutes ISR’s value (becomes SSR-equivalent); too long lets users see stale info longer. Adjust around Next.js’s revalidate: 60 baseline per page nature — practical operations.

Even within one site, methods cut per page. Giving up on unifying to one method is modern.

Three scenarios

If you are building solo or at a startup

For a blog, a landing page or a portfolio, SSG on Astro or Next.js is the only choice worth considering. It is served from a CDN, so server failures stop being your problem, and the cost is close to zero. Even when building an application, starting with SSG and switching to CSR only behind the login is a simple two-way split that is entirely sufficient.

Personal / Startup: Ship in One Month Is Correcten.senkohome.com/arch-intro-case-startup/

If you are a small or mid-size SaaS

This is the stage where you start explicitly designing the split by page type: SSG for marketing pages, ISR for product listings and detail pages (revalidate between 60 and 300 seconds), and SSR or CSR for the SaaS screens themselves. The more directly SEO drives revenue — an e-commerce site, for instance — the larger the effect of ISR.

Small-Mid SaaS - Lean on Managed and Run with Few Peopleen.senkohome.com/arch-intro-case-saas/

If you are a large enterprise

At this size the real issue becomes coexistence with what already exists. Keeping the legacy server-side rendering (JSP, Rails and the like) in place while carving out only the new screens into Next.js SSR or ISR — a Strangler Fig staged migration — is the realistic answer. The one thing to avoid is a big-bang full replacement.

Large-Enterprise Core: Design That Holds Up for Yearsen.senkohome.com/arch-intro-case-enterprise/

AI decision axes — Convention-based frameworks raise the AI’s generation accuracy

Convention-based FWs boost AI generation accuracy

Next.js App Router’s app/ directory conventions (page.tsx = page, layout.tsx = layout, loading.tsx = suspense) are clear structural rules for AI. Given “create a /dashboard/settings page,” AI accurately creates app/dashboard/settings/page.tsx and generates layout.tsx as needed.

With custom routing designs or hand-written SSR configurations, project-specific rules must be taught to AI each time, and accuracy doesn’t stabilize.

Server Components and Client Components boundary design

With the 'use client' directive at file tops deciding server/client boundaries, AI can judge per-file what runs where. This explicit boundary reduces mistakes like AI calling browser APIs in server components. Astro’s client:load / client:idle directives are similarly AI-friendly due to their explicitness.

Pitfalls and forbidden moves

Here are the six most dangerous routes into degraded performance, exploding cost and lost SEO.

The Vercel serverless-function billing incident of 2022 is the case where bots hit SSR pages and the invoice ran into the millions of yen. The iron rule is to serve statically anything that can be served statically.

Author’s note — the night “SSR on every page” caught fire

“A project with all marketing pages (which would be fine static) on Next.js SSR ran out of Vercel function-execution quota on the first night of a campaign and had to switch to static generation overnight” is a story repeated in many sites. Server cost growing linearly with traffic is what’s scary about SSR; campaigns and viral SNS hits spin the cost meter instantly.

A new-grad team builds an e-commerce site on Next.js SSR; a Friday-evening TV-tied campaign spikes requests, and Monday morning’s invoice shocks the manager — same family. The lesson is simple: starting with Static First would have avoided the accident.

Trying to build product detail and admin pages with the same method always makes one unhappy. Static for static-OK pages (SSG/ISR), SSR only for genuinely dynamic, CSR after login — “per-page selection” is the only way to reconcile cost, UX, and operations.

“All-page SSR” is a time bomb. Start Static First; dynamicize only required parts.

What you must decide — what’s your project’s answer?

Articulate your project’s answer in 1-2 sentences for each:

• Main rendering method (per-page basis)
• Hydration strategy (whole / Islands / Partial)
• RSC adoption
• Build frequency (for SSG)
• ISR revalidate window (seconds)
• Server-failure fallback method

Related Articles

Summary

This article covered rendering methods — CSR/SSR/SSG/ISR, Hydration/Islands, Streaming SSR, RSC.

Not “which is strongest” but “which fits which page.” Pick by use case, lean on convention-based FWs — the 2026 realistic answer.

The next article covers state management (useState / Context / Redux / Zustand / TanStack Query).

Back to series TOC -> ‘Architecture Crash Course for the Generative-AI Era’: How to Read This Book

I hope you’ll read the next article as well.