Choosing the Right Rendering Strategy: SSR, CSR, Static & Rehydration Explained

Introduction

Choosing where rendering occurs—server‑side, client‑side, static generation, or rehydration—affects performance, SEO, and development complexity. This summary outlines the core concepts, metrics, and techniques for each approach.

Key Terminology

SSR : Server‑Side Rendering – generates full HTML on the server and sends it to the client.

CSR : Client‑Side Rendering – the browser builds the UI entirely with JavaScript.

Rehydration : After SSR, the client loads JavaScript to “activate” the server‑rendered markup.

Prerendering : Runs the client application at build time to produce static HTML.

Performance Metrics

TTFB : Time to First Byte – latency from request to first byte received.

FP : First Paint – when any pixel becomes visible.

FCP : First Contentful Paint – when the first meaningful content appears.

TTI : Time To Interactive – when the page is fully usable.

Server‑Side Rendering (SSR)

SSR renders the complete page on the server, reducing the JavaScript payload sent to the client and typically yielding fast FP and FCP. The trade‑off is higher server CPU usage and potentially slower TTFB because the HTML must be generated per request.

Common SSR implementations:

React: renderToString() or frameworks such as Next.js.

Vue: Nuxt.js.

Angular: Angular Universal.

Static Rendering

Static rendering generates an HTML file for each URL at build time. Because the HTML is pre‑computed, FP, FCP, and TTI are consistently fast, and the files can be served from CDNs with edge caching.

Tools:

Gatsby (React).

Jekyll.

Metalsmith.

Drawback: a separate HTML file must be produced for every possible URL, which can be difficult for large, dynamic sites.

SSR vs. Static Rendering

SSR incurs higher server computation and may increase TTFB, while static rendering provides stable initial paint times. Hybrid approaches—SSR for personalized pages combined with HTML caching, or static generation for mostly static content—can balance the trade‑offs.

Client‑Side Rendering (CSR)

CSR runs the entire application in the browser. All data fetching, templating, and routing happen client‑side, which can lead to large JavaScript bundles and slower TTI, especially on mobile networks.

Performance mitigations:

Code‑splitting and lazy loading.

Critical resource preloading with <link rel="preload"> or HTTP/2 Push.

PRPL pattern (Push, Render, Pre‑cache, Lazy‑load).

Application Shell cached via Service Workers.

Rehydration & Universal Rendering

Universal rendering (SSR + rehydration) sends HTML plus the JavaScript needed to “activate” the UI on the client. This yields fast FCP but can delay TTI because the page remains non‑interactive until the bundle loads.

Challenges:

Duplicate build steps (server and client) increase build time and memory usage.

Serialized UI state enlarges the payload.

On low‑end devices the page may appear rendered but be unresponsive (“uncanny valley”).

Streaming SSR & Progressive Rehydration

Streaming SSR sends HTML in chunks, allowing the browser to start rendering before the full response arrives. In React, renderToNodeStream() provides asynchronous streaming, reducing back‑pressure compared to renderToString().

Progressive rehydration initializes only the parts of the UI that need interactivity first, deferring the rest. This reduces the initial JavaScript size and avoids tearing down the server‑rendered DOM.

Partial Rehydration

Partial rehydration extends progressive rehydration by lazily loading JavaScript solely for interactive components, leaving static sections with near‑zero client footprint. It introduces caching complexity and requires careful handling of navigation between partially hydrated pages.

Trisomorphic Rendering

Trisomorphic rendering shares templates and routing code across three contexts: server, client, and service worker. The initial HTML can be generated on the server (or via a streaming service worker), and the service worker can later render additional views as HTML, keeping cached components up‑to‑date while supporting SPA‑style navigation.

SEO Considerations

SSR provides a complete HTML snapshot that crawlers can index easily, improving SEO out‑of‑the‑box. CSR may require additional testing (e.g., Google Mobile Friendly Test) to ensure search engines can render the content. For heavily JavaScript‑driven sites, dynamic rendering can be used as a fallback.

Conclusion

When selecting a rendering strategy, measure the actual bottlenecks (TTFB, FP, FCP, TTI) and consider the proportion of pages that need personalization versus static content. A hybrid approach—static generation for the majority of pages, SSR with caching for personalized views, and minimal JavaScript for interactivity—often provides the best balance of performance, SEO, and developer productivity.