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).
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.
This allows components that may not be essential to be initialized later, reducing overall load time.
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?
The technique combines both SSR and CSR.
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.
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.
Featured image: UnderhilStudio/Shutterstock