Rehydration for client-side or server-side rendering

Rehydration, or simply “hydration,” is a term that comes up often when we discuss SPAs and server-side rendering.

Hydration essentially does not affect search engine optimization, but it is an essential step in delivering 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 has been rendered on the server side.

This may not matter to search engines, but it is essential if the site is to serve rendered, interactive components to users.

This process is used in Single Page Applications (SPAs) alongside server-side rendering, allowing for faster 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, which is serialized by the renderer, and booting the JavaScript components into interactivity using JavaScript loaded or linked in the HTML response.

As a general term, hydration in this case means that all components on the web page are initialized.

This can result in better Core Web Vital results and inherently requires less effort for Googlebot to render the webpage. In addition, search engines can index pages faster because they don’t have to go through Google’s WRS (Web Rendering Service).

Progressive rehydration explained

Progressive rehydration optimizes rendering and interactivity of individual components and includes both server-side rendering and client-side rendering (CSR) as parts of a page are launched over time.

Progressive rehydration essentially allows JavaScript components to lazily load, hydrating nodes over time rather than hydrating all nodes at once.

This allows components that may not be essential to be initialized later, reducing overall load time.

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 when a server-rendered Document Object Model (DOM) tree is destroyed and immediately rebuilt.

What is partial rehydration?

Another form of rehydration, partial rehydration, allows JavaScript components—or more specifically, “islands”—to be selectively hydrated without having to hydrate all components.

The technique combines both SSR and CSR.

In this scenario, the server sends an initial HTML document to the client along with content rendered by the server. Once loaded, the client-side JavaScript initiates and manipulates the DOM to add or update existing content on specific “islands”.

This means that JavaScript selectively updates parts of the page and not the entire page.

Partial rehydration is considered a powerful technique for performance-optimizing SPAs to charge for performance and efficiency.

However, there are also problems as it can pose problems with caching and client-side navigation.

A look at trisomorphic rendering

Trisomorphic rendering is less common in both the development and technical SEO community.

The process includes rendering SPAs on server and client side, as well as a service worker rendering HTML for navigation use.

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

In the development world, this means that cached components and templates can be kept up-to-date and that SPA-style navigations can be enabled to render new views in the same session.

When is the best time to rehydrate?

Rehydration is a necessity for sites that need to be highly interactive, such as B. Single page applications as it allows for faster initial load times and improved user experience.

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

There are also alternatives to hydration, such as B. Resumability, which differs in where and when the code runs.

Resumability can be an alternative to hydration and almost eliminate the need for JavaScript to run on page launch – meaning almost “instant” apps as opposed to a hydration process.

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

The client then resumes the application from where the server serialized it. Then when a user interacts with a page element, only that event handler is requested and executed when needed.

Resumable and resumeable frameworks are not new. Google internally used a resumeable framework called Wiz for search and photo products, and eBay uses a framework called Marko that added resumeability as a feature.

More resources:

Featured image: UnderhilStudio/Shutterstock