Every modern web framework asks you to choose how pages are rendered. Server-side rendering (SSR), static site generation (SSG), and client-side rendering (CSR) each have distinct tradeoffs in performance, SEO, developer experience, and infrastructure cost. Understanding these strategies helps you pick the right approach for each page in your application.
How each strategy works
CSR (Client-Side Rendering) — The server sends a minimal HTML shell with a JavaScript bundle. The browser downloads and executes JavaScript, which renders the entire page. The user sees a blank or loading screen until JavaScript finishes executing. React SPAs (Create React App) and Vue SPAs use this approach by default.
SSR (Server-Side Rendering) — The server generates complete HTML for each request. The browser receives a fully rendered page immediately, then JavaScript “hydrates” the page to make it interactive. Frameworks like Next.js and Remix support SSR out of the box.
SSG (Static Site Generation) — Pages are pre-rendered at build time into static HTML files. These files are served directly from a CDN without any server processing. Frameworks like Astro, Hugo, and Eleventy specialize in SSG.
Side-by-side comparison
| Feature | CSR | SSR | SSG |
|---|---|---|---|
| Initial load speed | Slow (JS must execute) | Fast (HTML ready) | Fastest (pre-built HTML from CDN) |
| SEO | Poor (empty HTML) | Excellent | Excellent |
| Time to Interactive | Slow | Moderate (hydration) | Fast |
| Server cost | Minimal (static hosting) | Higher (compute per request) | Minimal (CDN only) |
| Data freshness | Real-time | Real-time | Stale until rebuild |
| Build time | Fast | Fast | Slow for large sites |
| Hosting complexity | Simple | Requires server/serverless | Simple |
When to choose CSR
CSR works best for applications behind authentication where SEO does not matter. Admin dashboards, internal tools, and SaaS applications where users are already logged in benefit from CSR’s simplicity. There is no server to manage, and the entire application runs in the browser.
CSR is also appropriate for highly interactive applications where nearly every element depends on client-side state. Real-time collaboration tools, design editors, and complex data visualization dashboards are natural CSR candidates.
The main drawback is the initial loading experience. Users see a blank page or spinner until JavaScript downloads and executes. On slow connections or low-powered devices, this delay can be significant. Search engines also struggle to index CSR content reliably.
When to choose SSR
SSR is the right choice when you need both SEO and dynamic, personalized content. E-commerce product pages, social media feeds, news sites, and any page where content changes frequently but must be indexable by search engines benefit from SSR.
SSR provides the best balance between SEO and data freshness. Each request generates up-to-date HTML that search engines can crawl immediately. Users see content instantly without waiting for JavaScript to render the page.
The tradeoff is infrastructure cost and complexity. Every page request requires server computation, which means you need a Node.js server or serverless functions. Frameworks like Next.js make this manageable, but it is more complex than serving static files. Build tools like Vite help optimize the development experience for SSR applications.
When to choose SSG
SSG is ideal for content that changes infrequently: blogs, documentation sites, marketing pages, and portfolios. Pre-built HTML served from a CDN provides the fastest possible load times and the lowest hosting costs. There is no server to scale, no cold starts, and no compute costs per request.
SSG also provides excellent security since there is no server-side code executing at request time. The attack surface is minimal — just static files on a CDN.
The limitation is data freshness. Content only updates when you rebuild and redeploy the site. For a blog that publishes daily, this is fine. For a product catalog with thousands of items changing hourly, pure SSG becomes impractical.
Hybrid approaches
Modern frameworks blur the lines between these strategies. Next.js supports all three on a per-page basis — you can use SSG for your marketing pages, SSR for your product catalog, and CSR for your admin dashboard, all in the same application.
Incremental Static Regeneration (ISR) combines SSG’s performance with SSR’s freshness. Pages are statically generated but automatically regenerate in the background after a specified time interval. This gives you CDN-speed responses with reasonably fresh data.
Astro’s island architecture takes another approach: pages are statically generated by default, but individual interactive components hydrate independently on the client. This minimizes JavaScript while preserving interactivity where needed.
Performance in practice
For pure content sites, SSG wins decisively. Pre-built HTML from a CDN edge node reaches users in under 50ms regardless of geographic location. There is no faster way to serve web content.
SSR adds server processing time (typically 50-200ms) plus network latency to the origin server. Edge SSR (running server rendering at CDN edge nodes) reduces this significantly but adds complexity.
CSR has the worst initial performance because the browser must download, parse, and execute JavaScript before any content appears. Subsequent navigations are fast (no server round trips), but the first load suffers.
SEO implications
Search engines can crawl SSR and SSG pages immediately because the HTML contains all content. CSR pages require JavaScript execution, which Google can do but with delays and inconsistencies. Other search engines (Bing, DuckDuckGo) have limited JavaScript rendering capabilities.
If organic search traffic matters to your business, avoid pure CSR for public-facing pages. Use SSR or SSG to ensure your content is immediately accessible to all crawlers.
Making your decision
Use SSG for content sites, blogs, documentation, and marketing pages. Use SSR for dynamic pages that need SEO — e-commerce, social platforms, and personalized content. Use CSR for authenticated applications where SEO is irrelevant and interactivity is the priority.
Most applications benefit from a hybrid approach. Choose a framework that supports all three strategies and apply the right one per page based on its specific requirements.
FAQ
Which rendering method is best for SEO?
SSG and SSR are both excellent for SEO because they serve complete HTML that search engines can crawl immediately. SSG has a slight edge because pages load faster from CDNs, and page speed is a ranking factor. CSR is the worst for SEO because search engines must execute JavaScript to see content, which is unreliable and introduces indexing delays.
Is SSR slower than SSG?
Yes, SSR is slower than SSG for initial page loads. SSG serves pre-built HTML directly from a CDN edge node with no server processing. SSR must generate HTML on each request, adding server computation time and origin network latency. However, SSR is faster than CSR because users receive complete HTML immediately rather than waiting for JavaScript execution.
When should I use CSR?
Use CSR for applications behind authentication where SEO does not matter: admin dashboards, internal tools, SaaS applications, and highly interactive editors. CSR is also appropriate when your entire page depends on client-side state and real-time data that cannot be pre-rendered. Avoid CSR for public-facing pages where search engine visibility or initial load performance matters.
Can I mix SSR and SSG?
Yes, modern frameworks like Next.js, Nuxt, and SvelteKit support mixing rendering strategies on a per-page basis within the same application. You can statically generate your blog and marketing pages while server-rendering your product catalog and user profiles. Incremental Static Regeneration (ISR) further blurs the line by statically generating pages that automatically refresh at specified intervals.