The hydration feature is available for developer preview. It's ready for you to try, but it might change before it is stable.
Hydration is the process that restores the server side rendered application on the client. This includes things like reusing the server rendered DOM structures, persisting the application state, transferring application data that was retrieved already by the server, and other processes.
Hydration improves application performance by avoiding extra work to re-create DOM nodes. Instead, Angular tries to match existing DOM elements to the applications structure at runtime and reuses DOM nodes when possible. This results in a performance improvement that can be measured using Core Web Vitals (CWV) statistics, such as reducing the First Input Delay (FID) and Largest Contentful Paint (LCP), as well as Cumulative Layout Shift (CLS). Improving these numbers also affects things like SEO performance.
Without hydration enabled, server side rendered Angular applications will destroy and re-render the application's DOM, which may result in a visible UI flicker. This re-rendering can negatively impact Core Web Vitals like LCP and cause a layout shift. Enabling hydration allows the existing DOM to be re-used and prevents a flicker.
Before you can get started with hydration, you must have a server side rendered (SSR) application. Follow the Angular Universal Guide to enable server side rendering first. Once you have SSR working with your application, you can enable hydration by visiting your main app component or module and importing provideClientHydration
from @angular/platform-browser
. You'll then add that provider to your app's bootstrapping providers list.
import { bootstrapApplication, provideClientHydration, } from '@angular/platform-browser'; ... bootstrapApplication(RootCmp, { providers: [provideClientHydration()] });
Alternatively if you are using NgModules, you would add provideClientHydration
to your root app module's provider list.
import {provideClientHydration} from '@angular/platform-browser'; import {NgModule} from '@angular/core'; @NgModule({ declarations: [RootCmp], exports: [RootCmp], bootstrap: [RootCmp], providers: [provideClientHydration()], }) export class AppModule {}
Important note: make sure that the
provideClientHydration()
call is also included into a set of providers that is used to bootstrap an application on the server. In applications with the default project structure (generated by theng new
command), adding a call to the rootAppModule
should be sufficient, since this module is imported by the server module. If you use a custom setup, add theprovideClientHydration()
call to the providers list in the server bootstrap configuration.
After you've followed these steps and have started up your server, load your application in the browser.
You will likely need to fix instances of Direct DOM Manipulation before hydration will fully work either by switching to Angular constructs or by using
ngSkipHydration
. See Constraints, Direct DOM Manipulation, and How to skip hydration for particular components for more details.
While running an application in dev mode, you can confirm hydration is enabled by opening the Developer Tools in your browser and viewing the console. You should see a message that includes hydration-related stats, such as the number of components and nodes hydrated.
Angular calculates the stats based on all components rendered on a page, including those that come from third-party libraries.
Hydration imposes a few constraints on your application that are not present without hydration enabled. Your application must have the same generated DOM structure on both the server and the client. The process of hydration expects the DOM tree to have the same structure in both places. This also includes whitespaces and comment nodes that Angular produces during the rendering on the server. Those whitespaces and nodes must be present in the HTML generated by the server-side rendering process.
The HTML produced by the server side rendering operation must not be altered between the server and the client.
If there is a mismatch between server and client DOM tree structures, the hydration process will encounter problems attempting to match up what was expected to what is actually present in the DOM. Components that do direct DOM manipulation using native DOM APIs are the most common culprit.
If you have components that manipulate the DOM using native DOM APIs or use innerHTML
or outerHTML
, the hydration process will encounter errors. Specific cases where DOM manipulation is a problem are situations like accessing the document
, querying for specific elements, and injecting additional nodes using appendChild
. Detaching DOM nodes and moving them to other locations will also result in errors.
This is because Angular is unaware of these DOM changes and cannot resolve them during the hydration process. Angular will expect a certain structure, but it will encounter a different structure when attempting to hydrate. This mismatch will result in hydration failure and throw a DOM mismatch error (see below).
It is best to refactor your component to avoid this sort of DOM manipulation. Try to use Angular APIs to do this work, if you can. If you cannot refactor this behavior, use the ngSkipHydration
attribute (described below) until you can refactor into a hydration friendly solution.
There are a few cases where if you have a component template that does not have valid HTML structure, this could result in a DOM mismatch error during hydration.
As an example, here are some of the most common cases of this issue.
<table>
without a <tbody>
<div>
inside a <p>
<a>
inside an <h1>
<a>
inside another <a>
If you are uncertain about whether your HTML is valid, you can use a syntax validator to check it.
When using the hydration feature, we recommend using the default setting of false
for preserveWhitespaces
. If this setting is not in your tsconfig, the value will be false
and no changes are required. If you choose to enable preserving whitespaces by adding preserveWhitespaces: true
to your tsconfig, it is possible you may encounter issues with hydration. This is not yet a fully supported configuration.
Make sure that this setting is set consistently in
tsconfig.server.json
for your server andtsconfig.app.json
for your browser builds. A mismatched value will cause hydration to break.If you choose to set this setting in your tsconfig, we recommend to set it only in
tsconfig.app.json
which by default thetsconfig.server.json
will inherit it from.
Hydration relies on a signal from Zone.js when it becomes stable inside an application, so that Angular can start the serialization process on the server or post-hydration cleanup on the client to remove DOM nodes that remained unclaimed.
Providing a custom or a "noop" Zone.js implementation may lead to a different timing of the "stable" event, thus triggering the serialization or the cleanup too early or too late. This is not yet a fully supported configuration and you may need to adjust the timing of the onStable
event in the custom Zone.js implementation.
There are several hydration related errors you may encounter ranging from node mismatches to cases when the ngSkipHydration
was used on an invalid host node. The most common error case that may occur is due to direct DOM manipulation using native APIs that results in hydration being unable to find or match the expected DOM tree structure on the client that was rendered by the server. The other case you may encounter this type of error was mentioned in the Valid HTML structure section earlier. So, make sure the HTML in your templates are using valid structure, and you'll avoid that error case.
For a full reference on hydration related errors, visit the Errors Reference Guide.
Some components may not work properly with hydration enabled due to some of the aforementioned issues, like Direct DOM Manipulation. As a workaround, you can add the ngSkipHydration
attribute to a component's tag in order to skip hydrating the entire component.
<example-cmp ngSkipHydration />
Alternatively you can set ngSkipHydration
as a host binding.
@Component({ ... host: {ngSkipHydration: 'true'}, }) class ExampleCmp {}
The ngSkipHydration
attribute will force Angular to skip hydrating the entire component and its children. Using this attribute means that the component will behave as if hydration is not enabled, meaning it will destroy and re-render itself.
This will fix rendering issues, but it means that for this component (and its children), you don't get the benefits of hydration. You will need to adjust your component's implementation to avoid hydration-breaking patterns (i.e. Direct DOM Manipulation) to be able to remove the skip hydration annotation.
The ngSkipHydration
attribute can only be used on component host nodes. Angular throws an error if this attribute is added to other nodes.
Keep in mind that adding the ngSkipHydration
attribute to your root application component would effectively disable hydration for your entire application. Be careful and thoughtful about using this attribute. It is intended as a last resort workaround. Components that break hydration should be considered bugs that need to be fixed.
We don't yet support internationalization with hydration, but support is coming. Currently, Angular would skip hydration for components that use i18n blocks, effectively re-rendering those components from scratch.
There are a number of third party libraries that depend on DOM manipulation to be able to render. D3 charts is a prime example. These libraries worked without hydration, but they may cause DOM mismatch errors when hydration is enabled. For now, if you encounter DOM mismatch errors using one of these libraries, you can add the ngSkipHydration
attribute to the component that renders using that library.
© 2010–2023 Google, Inc.
Licensed under the Creative Commons Attribution License 4.0.
https://angular.io/guide/hydration