Server-Side Rendering (SSR)

Unlike static site generation which builds pages at deploy time, SSR executes the application code on the server at the moment of the request. The server fetches necessary data, renders the component tree to an HTML string, and sends a fully populated document. This ensures users always receive the most current data without waiting for client-side JavaScript to hydrate and fetch. The server handles the initial render, while the client takes over subsequent navigation through a process called hydration, where event listeners and state are attached to the existing DOM.

SSR sends complete, crawlable HTML to search engine bots on the first response. This is critical because while modern crawlers can execute JavaScript, they often impose render budgets and may delay indexing client-rendered content. With SSR, all textual content, meta tags, and structured data are immediately available in the source. This guarantees that page titles, descriptions, and body content are indexed reliably, making SSR the standard for content-heavy sites where organic discovery is a primary acquisition channel.

SSR improves First Contentful Paint (FCP) by sending pre-rendered markup, but it increases Time to First Byte (TTFB) because the server must complete all data fetching and rendering before sending a single byte. This creates a performance paradox:

• Faster FCP: The browser can begin painting immediately upon receiving HTML.
• Slower TTFB: The user stares at a blank screen longer before any response arrives. Mitigation strategies include streaming SSR, which sends HTML chunks as they are generated, and aggressive server-side caching of rendered output.

After the server sends the HTML, the page appears complete but is non-interactive until the client-side JavaScript bundle downloads, parses, and executes. This process, called hydration, reconciles the server-rendered DOM with the client-side framework's virtual DOM. During this gap, clicks and inputs may be ignored, leading to a frustrating uncanny valley of perceived performance. Frameworks like React 18 address this with Selective Hydration and Server Components, which allow parts of the page to become interactive independently without blocking the entire application.

Every request triggers a full render cycle, consuming CPU and memory on the server. This makes SSR computationally expensive compared to serving static files from a CDN. High-traffic applications must implement:

• Multi-tier caching: Caching rendered HTML at the CDN edge, with cache invalidation strategies tied to content updates.
• Render scaling: Horizontal scaling of Node.js server instances to handle traffic spikes.
• Partial prerendering: Pre-rendering static shells for dynamic content to reduce server work. Without these optimizations, SSR can become a bottleneck under load, increasing infrastructure costs significantly.

Modern SSR frameworks support streaming HTML using protocols like HTTP chunked transfer encoding. Instead of waiting for the entire page to render, the server sends the static shell immediately and streams in slower, data-dependent components as they resolve. React's renderToPipeableStream and frameworks like Next.js App Router enable this pattern. Benefits include:

• Faster TTFB: The browser receives the initial HTML shell without delay.
• Progressive loading: Users see content appear incrementally, improving perceived performance.
• Suspense integration: Components can suspend rendering on the server, with fallback UI streamed until data resolves.