SSR renders pages on each request, SSG pre-renders at build time, ISR adds background updates to SSG, and CSR renders in the browser—choose based on data freshness needs, performance requirements, and user personalization

Next.js offers four primary rendering strategies: Server-Side Rendering (SSR), Static Site Generation (SSG), Incremental Static Regeneration (ISR), and Client-Side Rendering (CSR). Each strategy determines when and where the HTML for your pages is generated, with different trade-offs in performance, SEO, data freshness, and user experience. Modern Next.js applications often combine multiple strategies within the same application, using SSG for marketing content, ISR for product pages, SSR for personalized dashboards, and CSR for interactive components that need real-time updates.

Quick Comparison Overview

1
SSR (Server-Side Rendering): HTML generated per request on the server. Best for personalized, user-specific content that needs to be fresh and indexable .
2
SSG (Static Site Generation): HTML generated at build time. Best for public, unchanging content where performance is critical .
3
ISR (Incremental Static Regeneration): SSG with background updates. Best for large sites where content changes but not instantly, combining static speed with freshness .
4
CSR (Client-Side Rendering): HTML generated in browser after JavaScript loads. Best for highly interactive, authenticated content where SEO isn't a priority .

SSR Example: Real-time Dashboard

SSG Example: Blog or Marketing Site

ISR Example: E-commerce Product Pages

CSR Example: Interactive Dashboard

To choose the right rendering strategy, ask these questions in order: First, does the page need SEO? If yes, you need server-rendered HTML (SSR, SSG, or ISR). Second, is the content personalized per user? If yes, SSR or client-side fetching after static shell. Third, how often does the data change? Real-time needs client-side updates; occasional updates work with ISR; never-changing works with SSG. Fourth, how many pages do you have? Large catalogs need ISR to avoid massive builds. Fifth, what's your performance budget? SSG gives the best Core Web Vitals scores, while SSR adds server time .

Strategy Selection Matrix

1
Marketing homepage: SSG with ISR (updates when campaigns change)
2
Blog posts: SSG (build-time generation, occasional updates via rebuild)
3
E-commerce product pages: ISR (popular pages pre-rendered, long-tail on-demand)
4
User dashboard: SSR for initial load + CSR for real-time updates
5
Admin panel: CSR (authenticated, SEO irrelevant, highly interactive)
6
Documentation site: SSG (content changes with version releases)
7
Social media feed: CSR with WebSockets (real-time, user-specific)
8
News article: ISR with on-demand (publish via webhook, instant update)

Hybrid Approach: Combining Strategies

SSG delivers the best performance (Time to First Byte under 100ms from CDN edge) and excellent SEO (complete HTML at load). SSR adds server processing time (typically 200-500ms TTFB) but still provides complete HTML for SEO. ISR gives SSG-like performance with freshness windows. CSR has the worst initial load performance (blank page until JS loads) and poor SEO unless using techniques like dynamic rendering or prerendering, which add complexity . Modern Next.js apps often use a hybrid strategy: SSG for content, ISR for updates, and CSR for real-time features within the same page.

Real-World Examples

1
Vercel Marketing Site: SSG for marketing pages, ISR for blog posts, SSR for dashboard after login
2
Nike.com: ISR for product pages (millions of products, updates with inventory), CSR for cart and checkout
3
The New York Times: ISR with on-demand for articles (publish via webhook), CSR for comments and real-time updates
4
Notion: CSR for the editor (highly interactive), SSR for public pages (documentation, marketing)