SSR vs CSR
Server-side rendering versus client-side rendering for web applications
SSR (Server-Side Rendering) generates HTML on the server for each request, delivering fully rendered pages to the browser. CSR (Client-Side Rendering) sends a minimal HTML shell with JavaScript that renders the page in the browser. SSR provides faster initial page loads and better SEO, while CSR enables richer interactivity and app-like experiences. Modern frameworks like Next.js and Nuxt blur the line by supporting both approaches.
SSR
Server-Side Rendering (SSR) is a web rendering strategy where the server generates the complete HTML for each page request and sends it to the browser. The browser receives a fully formed document that can be displayed immediately, without waiting for JavaScript to execute. After the initial render, client-side JavaScript "hydrates" the page, attaching event listeners and enabling interactivity. SSR was the original web paradigm (PHP, Rails, Django all render server-side by default), fell out of favor during the SPA (Single Page Application) era, and has returned in modern form through frameworks like Next.js, Nuxt, SvelteKit, and Astro. Modern SSR can be combined with streaming (sending HTML chunks as they are generated), partial hydration (only hydrating interactive components), and ISR (Incremental Static Regeneration, which caches rendered pages and revalidates them periodically). SSR's primary benefits are SEO (search engine crawlers receive fully rendered HTML), initial load performance (users see content before JavaScript loads), and accessibility (the page works before JavaScript initializes). The tradeoff is server load: every request requires server-side computation, and navigation between pages triggers full server round-trips unless combined with client-side routing.
CSR
Client-Side Rendering (CSR) is a web rendering strategy where the server sends a minimal HTML document (often just a div and a script tag), and JavaScript running in the browser fetches data and renders the full page UI. The browser does all the heavy lifting: downloading the JavaScript bundle, executing it, fetching API data, and constructing the DOM. CSR became dominant through SPA frameworks like React (Create React App), Angular, and Vue. It enables rich, interactive, app-like experiences with instant navigation (no full page reloads), complex state management, and offline capabilities. Once the initial bundle loads, subsequent interactions are fast because only data (not full HTML pages) is fetched from the server. CSR's primary benefits are interactivity (smooth transitions, real-time updates, complex UI state), reduced server cost (the server only serves static files and API endpoints), and deployment simplicity (the frontend is just static files served from a CDN). The tradeoff is initial load performance: users see a blank page until the JavaScript bundle downloads, parses, and executes. This can be several seconds on slow networks. SEO is also problematic because search engine crawlers may not execute JavaScript fully, though modern crawlers (Googlebot) have improved significantly.
Key Differences
- **Where rendering happens**: SSR renders on the server. CSR renders in the browser. - **Initial load**: SSR shows content immediately (HTML arrives ready). CSR shows a blank page until JavaScript loads and executes. - **SEO**: SSR provides fully rendered HTML for crawlers. CSR requires JavaScript execution, which some crawlers handle poorly. - **Interactivity**: CSR enables richer client-side interactions. SSR requires hydration to become interactive. - **Server cost**: SSR requires server compute for each request. CSR serves static files from a CDN. - **Navigation**: CSR provides instant, app-like page transitions. SSR traditionally requires full page reloads (mitigated by modern frameworks with client-side routing). - **Bundle size**: CSR sends large JavaScript bundles upfront. SSR sends rendered HTML with smaller JS for hydration. - **Time to interactive**: SSR shows content faster but may be slower to become interactive (hydration). CSR is blank longer but fully interactive once loaded.
When to Use Each
**Use SSR** for content-heavy sites where SEO matters (blogs, e-commerce, marketing pages, documentation), for applications where initial load speed is critical (users on slow connections, mobile-first markets), and when content changes frequently but must be crawlable. **Use CSR** for highly interactive applications where SEO is less important (dashboards, admin panels, internal tools, SaaS apps behind login), for offline-capable PWAs, and when the user experience benefits from app-like navigation. Most modern projects use a hybrid: SSR for initial loads and landing pages, CSR for interactive features after hydration.
Analogy
SSR is like a restaurant that prepares your meal in the kitchen and brings it to your table ready to eat. You see food immediately, but every course requires a trip to the kitchen. CSR is like a meal kit delivery: you get the raw ingredients (JavaScript bundle) and cook everything yourself (browser rendering). The first meal takes a while to prepare, but once your kitchen is set up, making new dishes (navigating pages) is fast.