Rehydration, or more simply ‘hydration,’ is a term that often comes up when we look at SPAs and server-side rendering.

Hydration does not, in essence, affect SEO but is an essential step for serving rendered pages to the user.

There are different types of hydration that can be used.

Different tech stacks and frameworks may already support different types of hydration.

What Is Rehydration?

Put simply, rehydration allows a web application or page to reach its interactive state after it is rendered on the server side.

This may not matter to search engines but is imperative to get right if the website serves rendered, interactive components to users.

This process is used in single-page applications (SPAs) alongside server-side rendering, which allows for a quicker First Contentful Paint (FCP), and client-side content is “hydrated” for the Largest Contentful Paint (LCP).

The process, therefore, involves capturing the current state of the page or app on the client-side serialized by the renderer, booting the JavaScript components into interactivity using JavaScript loaded or linked to in the HTML response.

As an overarching term, hydration, in this instance, means that all components on the webpage are initialized.

This can lead to better Core Web Vital results and inherently requires less effort from Googlebot to render the webpage. Moreover, search engines can index pages quicker, as this does not have to pass through Google’s WRS (Web Rendering Service).

Progressive Rehydration Explained

Progressive rehydration optimizes the rendering and interactivity of individual components, and involves both server-side rendering and client-side rendering (CSR) as pieces of a page are booted over time.

Progressive rehydration allows for JavaScript components to essentially be lazy-loaded, where nodes are hydrated over time rather than all the nodes being hydrated at once.

This allows for components that might not be essential to be initialized later, making the total loading time shorter.

In fact, both users and search engine bots and crawlers can start seeing and interacting with the pages as soon as HTML is rendered – even before the JavaScript is executed.

Progressive rehydration also helps avoid common SSR pitfalls, such as where a server-rendered Document Object Model (DOM) tree is destroyed and immediately rebuilt.

What Is Partial Rehydration?

Another form of rehydration, partial rehydration, allows for the selective hydration of JavaScript components – or, more specifically, ‘islands’ – without having to hydrate all components.

The technique combines both SSR and CSR.

In this scenario, the server sends an initial HTML document alongside server-rendered content to the client. Once loaded, the client-side JavaScript initiates and manipulates the DOM to add or update existing content on specified ‘islands.’

This means that the JavaScript selectively updates parts of the page rather than the entirety.

Partial rehydration is seen as a powerful technique for performance-optimizing SPAs for loading performance and efficiency.

That said, it does have its issues, as it can present challenges for caching and client-side navigation.

A Look At Trisomorphic Rendering

Trisomorphic rendering is less common across both development and technical SEO communities.

The process involves rendering SPAs across server and client sides, as well as on a service worker to render HTML for the use of navigations.

The process uses a mix of streaming server-side rendering, which renders initial navigations, and the service worker renders HTML for navigations. The streaming server-side rendering ensures the necessary content is sent to search engines.

In the world of development, it means that cached components and templates can be kept up-to-**** and that SPA-style navigations for rendering new views in the same session can be enabled.

When Is It Best To Use Rehydration?

Rehydration is a necessity for websites that need to be highly interactive, such as single-page applications, because it allows for faster initial load times and improved user experience.

Picking a specific type of hydration requires knowledge of how your tech stack works and what works best for your website.

There are also alternatives to hydration, such as resumability, which differs on where the code executes and when it executes.

Resumability can be an alternative to hydration and can almost remove the need for JavaScript to be executed as the page starts up – meaning almost “instant” apps versus a hydration process.

When the client sends a request to the server, the server first rebuilds the application and serializes it into HTML. The HTML is then returned to the client.

The client then resumes the application from the point the server serialized it; then when a user interacts with a page element, only that event handler is requested and executed on demand.

Resumability, and resumable frameworks, are not new. Google has used a resumable framework internally named Wiz for Search and Photos products, and eBay uses a framework called Marko which has added resumability as a feature.

More resources:

Featured Image: UnderhilStudio/Shutterstock