How Hydration Works in Server-Side Rendering (SSR)

Image By Neha Gupta

Introduction

We all have heard about Hydration most of the time while working with Server Side Rendering.

Let’s understand what happens in hydration in detail.

Brief Introduction to Server-Side Rendering

In server-side rendering server generates a fully rendered HTML at the server side for each request and sends it to the client so that the client receives a ready-to-display page.

To know more about Server-side and Client-side rendering you can go through this article.

What is Hydration?

To understand hydration let’s first understand the process of server-side rendering.

  1. The client(user) requests a webpage from the server ex- Home page
  2. The server returns a completely constructed HTML page to the client this means all the context like text, images, etc is generated and sent as a fully formed HTML document mostly including static content like headers, footers, and main page layout.
  3. The page the client gets is currently static and has no dynamic behavior, which comes with JavaScript ex-form validation, event listeners, etc.
  4. At this point, the static page is rendered by the browser it received from the server, meaning the page is fully rendered but has yet to be interactive.

Now comes the Hydration Process which will be going to make the page interactive.

Once the browser receives the HTML it also loads the associated JavaScript bundles with it (which were either referenced in the HTML or included as separate script tags).

Hydration happens when the JavaScript on the client takes control of the static HTML content. This process includes:

  • Binding the Event Listeners: Adding event listeners to the elements like buttons, text fields, etc.
  • Rehydrating the state: The server might have sent some initial state with the page (for example, the initial state of a React component). The client-side JavaScript rehydrates this state so that any dynamic or interactive functionality works as expected.
  • Setting up dynamic updates: For example, React or Vue.js (or another framework) will begin handling user interactions, and update the UI as necessary, such as changing the view after a button click, updating form inputs, etc.

The client-side JavaScript framework takes over during hydration, turning the static HTML into a fully interactive page, turning the page into a “live” application.

Common Issues in Hydration

  • The client-side rendered content must match the pre-rendered HTML on the server. If there’s a mismatch between the HTML from the server and the HTML generated by the client, it can lead to bugs or performance issues.
  • Since Hydration is a costly process as it involves the browser must render the static content, load the JavaScript, and then attach all the necessary event listeners and re-initialize the state. It can lead to delays and affect the user experience if not handled properly.
  • If the JavaScript loads after the HTML, there can be a visual flash or flicker, where the user sees the static content and then sees it “shift” or update when the JavaScript takes control.

Queries and Doubts

Thanks for the read :) Hope you have enjoyed reading it 🤩 and learned something new today.

If you have any doubts or queries feel free to drop a comment or

⁍ Connect with me on my 🔗Topmate 💬.

⁍ You can also reach out to me on my 🔗LinkedIn.

⁍ Please clap for this post if you enjoyed reading it 📗 and follow for more interesting articles.

⁍ You can also support me and my writings by treating me to a nice virtual cup of coffee ☕️.