Server Side Rendering in React
Aswin Prasad
SDE-I @ AEREO | Crafting Seamless Web & Mobile Experiences | React | React Native
Understanding the Fundamentals of Server Side Rendering
Ever clicked a link to a web application and found yourself staring at a blank white screen? That moment of uncertainty - is the page loading, or is something broken?🤔 This is one of the core challenges that modern web applications face, and it's where Server Side Rendering (SSR) comes into play. Whether you're building your next project or scaling an existing one, understanding SSR isn't just about following a trend - it's about delivering better user experiences.
In the early days of React, the dominant approach was "client-side" rendering. Users would get a bare-bones HTML file structured like this:
<!DOCTYPE html>
<html>
<body>
<div id="root"></div>
<script src="/static/js/bundle.js"></script>
</body>
</html>
The bundle.js file contains everything needed to power the application - React itself, third-party packages, and our application code.
After downloading and processing the JS, React kicks into gear, generating all necessary DOM nodes and placing them within that empty <div id="root"> container.
The challenge? This process isn't instant. Users face a blank screen while waiting for everything to download and initialize. What's worse, this delay typically increases as applications grow - each feature we add increases our JavaScript bundle size, extending the wait time for users.
This is where Server Side Rendering enters the picture. Rather than sending a blank HTML file, SSR generates the complete HTML on the server. Users receive a fully-formed document right away.
While this HTML still includes the <script> tag (React needs to handle interactivity on the client), React behaves differently in the browser: instead of creating DOM nodes from scratch, it works with the existing HTML. This process is called hydration.
As Dan Abramov from the React team elegantly explains:
Hydration is like watering the “dry” HTML with the “water” of interactivity and event handlers.
After downloading the JavaScript bundle, React examines the application, creates its virtual UI representation, and connects it with the existing DOM, adding event handlers and initializing effects.
That's the essence of SSR: server-generated HTML eliminates the blank screen during JavaScript processing, while client-side React adds the necessary interactivity.
The Data Flow Challenge
Let's examine data-fetching in React. Traditional setups involve two separate systems communicating over the network:
Using tools like React Query, SWR, or Apollo, the browser-side application requests data from the backend, which fetches it from the database and sends it back.
Understanding These Visualizations
These graphs illustrate data movement between browser (client) and server (backend API) across different rendering approaches.
The timeline uses arbitrary units rather than real time measurements. In practice, these durations vary significantly based on numerous factors. These visualizations aim to convey concepts rather than exact timings.
The first graph demonstrates Client Side Rendering (CSR). The process begins with an HTML file reaching the client. While this file lacks content, it includes the necessary <script> tags.
After JavaScript downloads and processes, the React application initializes, creating DOM nodes and structuring the UI. However, without initial data, we can only show a skeleton layout (header, footer, basic structure) with loading indicators.
Recommended by LinkedIn
This pattern is common - think of how UberEats displays a skeleton screen while loading restaurant data.
Users see this loading state until data arrives and React updates the display with actual content.
Now, let's explore an alternative architecture using Server Side Rendering:
Here, the initial render happens server-side, delivering an HTML file with actual content.
While this improves things - seeing a layout beats staring at a blank page - it's not a complete solution. Users want actual content, not loading screens (whether they're looking for restaurants, hotels, search results, or messages).
To really get a sense of the differences in user experience, let's add some web performance metrics to our graphs:
To better understand the user experience impact, let's examine some performance metrics:
Server-side rendering enables faster initial layout display, creating a sense of progress. Sometimes this matters - perhaps users just need the navigation header to load so they can click elsewhere.
But doesn't something seem inefficient here? Looking at the SSR diagram, we see the request beginning server-side. Why make a second network round-trip when we could handle the database work during that first request?
In other words, why not structure it like this?
This approach eliminates the client-server ping-pong, delivering a complete UI immediately.
But how would we implement this?
It would require telling React to execute certain code exclusively on the server for database queries. However, this hasn't been possible with React - even with SSR, components render both server-side and client-side.
Coming up next: I'll explain how React Server Components from the new React v19 transform this landscape! Stay tuned!
Let's connect on LinkedIn: www.linkedin.com/in/aswin-prasad
#ReactDevelopment #WebPerformance #JavaScript #FrontendDevelopment #WebDev #Programming
Follow for more insights into React and modern web development!
Software Developer | Dedicated to Continuous Improvement and Making Positive Impacts | Proficient in JavaScript, React Native, ReactJs, Redux, Context API, React Hooks, Native Modules, NodeJs, MongoDb and Firebase.
4moInteresting
aSDE @Swiggy | Java Backend Developer
4moVery informative