A concise technical guide explaining the two dominant web rendering strategies — Server-Side Rendering (SSR) and Client-Side Rendering (CSR) — covering how each works, their trade-offs, and when to choose one over the other.
Server-Side Rendering (SSR) means the web server generates the full HTML for a page on each request and sends it directly to the browser. Client-Side Rendering (CSR) means the server sends a minimal HTML shell plus a JavaScript bundle, and the browser executes that JS to build and render the UI. Both approaches produce the same visible result but via fundamentally different pipelines. Frameworks like Next.js support SSR, while classic React or Vue SPAs default to CSR.
When a user requests a URL, the server runs the application code, fetches any required data, and interpolates it into HTML before responding. The browser receives ready-to-display markup and can paint content almost immediately. A secondary process called hydration then attaches JavaScript event listeners to the static HTML, making it interactive. This means the user can see content before all JS has finished parsing.
The server responds with a near-empty HTML file and a reference to a JavaScript bundle. The browser downloads, parses, and executes that bundle, which in turn fetches data via APIs and constructs the DOM dynamically. Until the JS executes, the user typically sees a blank screen or loading spinner. Once loaded, subsequent navigation is extremely fast because only data — not full pages — travels over the network.
SSR delivers a faster First Contentful Paint (FCP) and is inherently crawler-friendly because search-engine bots receive fully populated HTML. CSR can suffer a slower initial load due to the large JS bundle and extra round-trips for data fetching. However, CSR excels at highly interactive applications where most users navigate within the app after the first load. Core Web Vitals like LCP (Largest Contentful Paint) and TTI (Time to Interactive) are directly impacted by this choice.
In SSR, hydration errors occur when the HTML rendered on the server does not exactly match what React (or another framework) would render on the client. This causes the framework to discard and re-render the DOM, negating SSR's performance benefit and sometimes breaking interactivity. Common causes include using browser-only APIs (e.g., window or document) during server rendering, or non-deterministic data like Date.now(). Always guard browser-specific code with environment checks such as typeof window !== 'undefined'.
Choose SSR when SEO is critical, content is dynamic and user-specific, or you need a fast initial paint for first-time visitors — e-commerce, blogs, and news sites are prime candidates. Choose CSR for internal dashboards, admin tools, or heavily interactive applications where SEO is irrelevant and users stay logged in across many views. Modern hybrid approaches like Next.js's Incremental Static Regeneration (ISR) or React Server Components let you mix both strategies at the component or route level for the best of both worlds.
© RM Full Stack & AI Engineer · All guides · Roadmaps · Open the app