What Is Server-Side Rendering and How It Works
Server-Side Rendering (SSR) is a web development technique where a server converts dynamic JavaScript components into fully formed HTML pages before sending them to the user’s browser. This article explains the fundamentals of SSR, details how server environments like Node.js execute JavaScript to produce markup, and explores the critical process of hydration that brings these static pages to life.
Understanding Server-Side Rendering
In traditional Client-Side Rendering (CSR), the server delivers an almost empty HTML document alongside a bundle of JavaScript files. The user’s browser must download, parse, and execute this JavaScript before rendering any visible content.
Server-Side Rendering inverts this model. When a user requests a URL, the server executes the necessary application logic, fetches required database or API data, and compiles the UI components directly into standard HTML. The browser receives a complete document that it can display immediately, significantly improving initial load times and search engine optimization (SEO).
How JavaScript Executes on the Server
Executing JavaScript on the server relies on a runtime environment, most commonly Node.js or modern alternatives like Deno and Bun. These runtimes provide the engine (such as Google’s V8) required to parse and run JavaScript code outside of a web browser.
The server-side execution process follows these key stages:
- Request Interception: The server receives an incoming HTTP request for a specific route.
- Data Fetching: Before rendering the UI, the server calls necessary APIs, databases, or microservices to gather the data required by the requested page.
- Component Execution: The server runs the frontend
JavaScript application code. In modern frameworks like React, Vue, or
Svelte, dedicated server-side APIs (such as React’s
renderToStringorrenderToPipeableStream) evaluate the component hierarchy and produce a static HTML string representing the final UI state. - HTML Construction: The generated HTML string is
injected into the base HTML template, alongside relevant
<head>metadata, CSS stylesheets, and references to client-side JavaScript bundles. - Response Delivery: The server sends the fully constructed HTML document back to the client with an HTTP 200 status code.
The Role of Hydration
While the server sends a fully rendered HTML page that users can read immediately, that page is initially static and non-interactive. To enable event listeners, state updates, and dynamic routing, the application undergoes a process called hydration.
Once the browser paints the server-rendered HTML, it downloads the client-side JavaScript bundle. The frontend framework executes in the browser, scans the existing DOM, attaches necessary event listeners (such as click or submit handlers), and initializes internal application state without re-rendering the HTML from scratch. Once hydration is complete, the application behaves as a fully interactive Single-Page Application (SPA).
Benefits and Trade-offs of SSR
Benefits
- Fast First Contentful Paint (FCP): Users see content almost immediately because the browser does not have to wait for large JavaScript bundles to download and execute before painting the screen.
- SEO Optimization: Web crawlers can easily index the fully rendered HTML without relying on complex JavaScript execution routines.
- Consistent Performance: Lower-powered mobile devices benefit from offloading the initial rendering workload to high-performance servers.
Trade-offs
- Increased Server Load: The server must expend CPU and memory resources to render pages for every incoming request, requiring robust caching strategies.
- Time to Interactive (TTI) Delays: A page may appear fully loaded before the client-side JavaScript has finished downloading and hydrating, leading to brief moments where user input is unresponsive.