← Back to Posts

In the world of web development, Rendering is the critical bridge between data and the user's eyes. It is the process of converting code (like your React components) into the final, visible HTML that a browser allows a user to see and interact with.

For years, the dominant pattern was the Single Page Application (SPA), which relies almost entirely on Client-Side Rendering (CSR). While powerful for interactivity, as these applications grew heavier, users began staring at loading spinners longer. This shift in user expectation and performance metrics has brought Server-Side Rendering (SSR) aggressively back into the spotlight.

This guide explores the rendering landscape, highlights the limitations of standard CSR/SPAs, and details the superior logic behind migrating to an SSR approach.

The Foundation: The Critical Rendering Path

Before diving into Server-Side Rendering (SSR), it's essential to understand the critical rendering path—the process of delivering the most important content to the browser as quickly as possible. The faster we deliver essential assets, the quicker the browser can render the page.

Steps in rendering Process

  1. Receiving the HTML Document: The browser establishes a connection and receives the initial HTML document (e.g., index.html), which acts as the blueprint, referencing all external assets (CSS, JavaScript, images).

  2. Fetching Assets: The browser begins parsing the HTML and fetches all linked, external assets required for the page's structure and appearance.

  3. Rendering HTML & CSS (First Paint): The browser uses the parsed HTML to construct the Document Object Model (DOM) and the parsed CSS to construct the CSS Object Model (CSSOM). Combining these creates the Render Tree. The page is rendered once CSS is fully parsed, as CSS is a render-blocking resource. This moment, when the first piece of content (text or image) is displayed, is called the First Contentful Paint (FCP). To prioritize FCP, developers often inline 'Critical CSS' directly into the HTML.

  4. Loading JavaScript: JavaScript files are loaded and executed after the HTML and CSS load, which can introduce delays if the files are large or the network is slow.

The last step involves downloading and executing JavaScript, which can introduce delays .To achieve a fast initial render, meaningful HTML and CSS should be prioritized , while JavaScript should be considered an enhancement that can be loaded asynchronously or deferred.

The Problem: The Client-Side Rendering (CSR) Bottleneck

In a traditional Single Page Application (SPA)—often called Client-Side Rendering (CSR)—the server sends a largely empty HTML file. This philosophy directly conflicts with the Critical Rendering Path's mandate for fast HTML delivery

The Logic of an SPA:

  1. Server: Sends <div id="root"></div>.

  2. Browser: Displays a white screen (or a generic spinner).

  3. Browser: Downloads a massive JavaScript bundle (e.g., main.js).

  4. Browser: Executes the JS, which generates the HTML and inserts it into the div.

  5. User: Finally sees the content.

Why Migrate from CSR/SPA to SSR?

While SPAs offer great transitions between pages, the initial load is often painful. Here is why developers are moving to SSR:

  • SPAs Delay First Content (Low FCP): Nothing inside the root element renders until a large JS bundle downloads, parses, and executes. On poor connections, users see a blank screen for seconds

  • SEO Issues: Search engines and social media crawlers prefer pre-rendered HTML. SSR instantly exposes the page structure and content to these services.

  • Performance Metrics: SPAs often suffer from poor First Contentful Paint (FCP) scores because the browser has to work hard just to show text.

  • SSR Improves Perceived Performance: Users see actual content immediately, even if JS hasn’t finished loading, reducing the psychological "waiting time."

  • SSR Enables Caching at the Edge: With SSR, the full HTML can be cached on a CDN, reducing load on the main server and drastically speeding up repeated requests.

The Solution: How Server-Side Rendering (SSR) Works

SSR flips the script. Instead of sending an empty shell, the server executes the application logic before sending the response.

The Logic of SSR:

  1. Server: Runs the React/JS code internally.

  2. Server: Generates a full HTML string (e.g., <div><h1>Hello World</h1></div>).

  3. Browser: Receives the HTML and displays it immediately.

  4. Browser: Downloads JavaScript in the background to make the page interactive.

Real-World Example

Imagine a news website.

  • With SPA: The user sees a spinning loader while the browser fetches the article data from an API.

  • With SSR: The server fetches the API data, populates the article text into HTML, and sends the readable page. The user reads the news immediately, even if the "Comment" button isn't clickable for another second.

Deep Dive: The Magic of Hydration

We established that SSR sends a complete HTML page to the browser for a fast initial render. But how does that static HTML, rendered by Node.js on the server, suddenly become a dynamic, interactive React application on the client? The answer is Hydration.

What is Hydration?

Hydration is the process where the client-side JavaScript "takes over" the server-rendered HTML. It performs three key actions:

  1. Attaching Listeners: It scans the existing HTML structure and attaches all the necessary event listeners (like onClick, onChange) to the DOM elements.

  2. State Initialization: It loads the application's initial state (which was often embedded in the server-rendered HTML) and mounts it to the component tree.

  3. Matching VDOM: It runs the client-side application and compares the resulting Virtual DOM (VDOM) against the existing HTML. If the structures match, React knows it can safely avoid a full re-render, thus saving precious time and CPU cycles.

Analogy: Think of the server-rendered HTML as a "dry sponge." It has the structure and shape (visual content), but it’s stiff. Hydration is the act of adding water (JavaScript) to the sponge, making it functional, flexible, and responsive to interaction.

SSR Trade-offs (and How to Solve Them)

Moving to SSR improves perceived performance, but it introduces new complexities that must be managed.

1. Rendering Cost (Server Load)

In an SPA/CSR, the user's browser does the heavy lifting. In SSR, your server does the work for every request.

  • Risk: High traffic can spike CPU usage.

  • Solution: Implement CDN Caching. Cache the generated HTML at the edge so the server only renders the page once every few minutes, not for every single user.

2. Time to Interactive (TTI) vs. First Contentful Paint (FCP)

SSR gives you a fast FCP (the user sees content quickly), but the TTI (time until the user can click) remains dependent on the JavaScript downloading.

  • The Uncanny Valley: This is the temporary state where the page looks ready (FCP is achieved), but clicking a button does nothing because the necessary client-side logic (known as hydration) has not completed. Optimizing JS size is crucial here.

  • Solution: Optimizing hydration via Code Splitting and advanced techniques like Progressive/Selective Hydration (only hydrating critical components first).

Conclusion: Embrace the Future, Stop the Double Render

The central failure of pure Client-Side Rendering (CSR) is that it forces the browser to render twice, compromising FCP, TTI, and essential SEO capabilities. CSR is still good for things like internal dashboards where users stay on the page for a long time. It makes everything feel smooth after the initial load.

Modern applications must excel at speed, SEO, Core Web Vitals, mobile performance, and global accessibility. This is where CSR begins to show its limits, and where SSR consistently outperforms it. By sending complete, meaningful HTML before JavaScript executes, SSR consistently outperforms CSR by dramatically improving:

  • First Contentful Paint (FCP): Delivering an instant visual experience.

  • SEO: Exposing full content immediately to crawlers.

  • Perceived Load Time: Reducing the psychological "waiting time."

The Verdict: Hybrid is the Future

In today's performance-driven web, SSR-driven hybrid models clearly outshine traditional CSR. The definitive answer is not one or the other, but a strategic combination.

Modern web development is embracing hybrid rendering models managed by powerful meta-frameworks. Tools like Next.js, Remix, and Tanstack Start along with others, automate this orchestration, providing features like Partial Hydration and React Server Components (RSC).