You're building a new website. The framework asks: SSG, SSR, ISR, or CSR?
If you choose wrong, you'll find out when Google doesn't index your pages, or when your users complain about load times.
Here's the simple guide.
The Four Rendering Strategies
SSG - Static Site Generation
Pages are rendered at build time and served as static HTML files.
How it works:
- During
npm run build, all pages are generated as HTML - HTML is served directly from CDN
- JavaScript hydrates for interactivity
Pros:
- Lightning fast load (HTML is ready)
- Perfect SEO (Googlebot sees everything)
- Cheap hosting (CDN)
- High security (no server logic)
Cons:
- Changes require new build
- Scales poorly to thousands of pages
- Data can become stale
Use for: Marketing sites, blogs, documentation.
SSR - Server-Side Rendering
Pages are rendered on the server for each request.
How it works:
- User requests page
- Server renders HTML with fresh data
- HTML is sent to browser
- JavaScript hydrates
Pros:
- Always fresh data
- Good SEO (HTML is ready at request)
- Personalization possible (cookies, auth)
Cons:
- Requires server (more expensive hosting)
- Slower TTFB (Time To First Byte)
- Server load during high traffic
Use for: E-commerce, news sites, personalized content.
ISR - Incremental Static Regeneration
The best of SSG and SSR. Pages are static but update in the background.
How it works:
- First request serves cached HTML
- In the background, page regenerates with fresh data
- Next request gets the updated version
Pros:
- Fast like SSG
- Fresh data like SSR
- Scales well
Cons:
- Only certain frameworks (Next.js, Nuxt)
- Complexity in cache invalidation
- First user may see stale data
Use for: Product pages, blogs with frequent updates, large sites.
CSR - Client-Side Rendering
The browser downloads an empty HTML file and JavaScript builds the entire page.
How it works:
- Server sends
<div id="root"></div> - Browser downloads JavaScript bundle
- JavaScript runs and renders UI
Pros:
- Fast navigation between pages (SPA feeling)
- Simple hosting (just static files)
- Good for apps behind login
Cons:
- Empty page until JS loads (bad First Contentful Paint)
- SEO is difficult: Googlebot needs to run JS
- Large bundles = slow initial load
Use for: Dashboards, admin panels, apps behind login.
SEO Implications
| Strategy | Google Indexing | First Contentful Paint | Data Freshness |
|---|---|---|---|
| CSR | Risky | Slow | Real-time |
| SSG | Perfect | Fastest | Stale |
| SSR | Perfect | Medium | Real-time |
| ISR | Perfect | Fast | Near real-time |
Google and JavaScript: Google can crawl JavaScript, but it's slower and less reliable. If SEO matters, choose SSG, SSR, or ISR.
Practical Examples
| Website Type | Recommended Strategy |
|---|---|
| Marketing landing page | SSG |
| Blog | SSG or ISR |
| E-commerce product pages | ISR |
| E-commerce cart/checkout | SSR or CSR |
| Dashboard behind login | CSR |
| News site | ISR or SSR |
| Documentation | SSG |
| Social media feed | CSR with SSR for SEO pages |
The Hybrid Approach
Most modern sites use multiple strategies:
/ → SSG (landing page)
/blog → SSG or ISR
/products/[id] → ISR (many pages, often updated)
/cart → CSR (personal, behind session)
/dashboard → CSR (behind login)
Next.js, Nuxt, and SvelteKit all support this out of the box.
Our Recommendation
- Start with SSG for all static content
- Use ISR for dynamic content that needs to be SEO-friendly
- Use SSR only when you need personalization or real-time data
- Use CSR behind login where SEO is irrelevant
If in doubt: ISR is the safest default for most projects in 2026.