Web DevelopmentBy Abdul Rahman22 Sept 20262 min read
Rendering Strategies Explained: SSR, SSG, ISR and Streaming
Choosing how each page is rendered affects speed, cost, SEO and freshness. A clear comparison of client rendering, SSR, SSG, ISR and streaming — and when to use each.
Modern frameworks let you choose, page by page, when and where HTML is generated. That choice affects page speed, hosting cost, SEO, and how fresh the data is. Understanding the options is now a core skill for full-stack developers.
Pick the most static strategy that still keeps the page's data fresh enough.
Client-Side Rendering (CSR)
The server sends a mostly empty HTML page and a JavaScript bundle; the browser fetches data and renders everything.
Good for: highly interactive, logged-in dashboards where SEO doesn't matter. Drawbacks: slower first paint, heavier JavaScript, weaker SEO.
Static Site Generation (SSG)
Pages are rendered once at build time and served from a CDN.
Good for: marketing pages, documentation, portfolios — content that rarely changes. Drawbacks: content changes require a rebuild.
Incremental Static Regeneration (ISR)
Pages are static, but regenerated in the background after a set interval or on demand:
export const revalidate = 300; // at most every 5 minutes
On this portfolio, the blog and home page use ISR: visitors get static-speed pages, new posts appear within minutes, and publishing from the admin panel triggers revalidatePath() so they appear immediately.
Good for: blogs, product catalogues, listings — mostly static content that changes occasionally.
Server-Side Rendering (SSR)
HTML is generated on every request with the latest data.
Good for: personalised or rapidly changing pages — account pages, search results, admin dashboards. Drawbacks: each request costs server time; slow data sources slow the whole page.
Streaming
Streaming SSR sends the page in chunks. The layout and fast content appear immediately; slower sections stream in as their data resolves, wrapped in <Suspense>:
export default function Dashboard() {
return (
<>
<Header />
<Suspense fallback={<StatsSkeleton />}>
<Stats /> {/* slow query — streams in when ready */}
</Suspense>
</>
);
}
Good for: pages mixing fast and slow data, where perceived performance matters.
How to Choose
Ask three questions for each route:
- Is the content the same for every visitor? If yes, prefer static (SSG/ISR).
- How fresh must it be? Seconds → SSR; minutes or hours → ISR; only on deploy → SSG.
- Does it need SEO? If yes, avoid pure client-side rendering.
Mixing strategies within one application is normal — and in the Next.js App Router it's configured per route.
Key Takeaways
- Choose the most static strategy that keeps data fresh enough.
- SSG for rarely changing pages, ISR for content that updates occasionally.
- SSR for personalised or real-time pages; stream slow sections with Suspense.
- Reserve pure client rendering for interactive, non-SEO areas.
