You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Enable withIncrementalHydration() by default in for SSR Angular projects #65263
Currently, Angular SSR applications generated with the Angular CLI (ng new --ssr) do not enable withIncrementalHydration() by default. Developers need to manually update the server configuration to opt in to incremental hydration.
Incremental hydration is now the recommended, modern hydration strategy and provides significant UX and performance benefits compared to the legacy full hydration approach. Because of this, it would be beneficial for developers if new SSR projects used this configuration automatically.
Please enable provideClientHydration(withIncrementalHydration()) in all newly generated Angular SSR applications.
Describe the solution you'd like
Suggested change:
When running:
ng new my-app --ssr
the generated app.config.ts (and/or other relevant project scaffolding) should automatically include:
Following a chat with @thePunderWoman, it was mentioned that before doing this we'd likely want to do some changes to the framework such as enable it by default make it default, not just add it in the schematic.
changed the title [-]Enable withIncrementalHydration() by default in new SSR Angular projects generated via Angular CLI[/-][+]Enable withIncrementalHydration() by default in for SSR Angular projects[/+]on Nov 17, 2025
changed the title [-]Enable withIncrementalHydration() by default in for SSR Angular projects[/-][+]Enable `withIncrementalHydration()` by default in for SSR Angular projects[/+]on Nov 17, 2025
I've been testing this a bit, and I see that if we have withIncrementalHydration set to default, the bundle size will increase by approximately 23kb. I'm not sure if it would be worth the cost for all users, considering that there may be some who don't use it (in my case, some projects I've participated in).
That said, I understand the importance. An alternative would be to perhaps have a other function / entry point?
provideIncrementalHydration(), which could be the new default for incremental hydration.
And we could keep provideClientHydration working as it does for those who don't need incremental hydration, as well as perhaps deprecating withIncrementalHydration.
@SkyZeroZx I think that provideIncrementalHydration() defeats the purpose of having it be the default behavior. We would also provide a way to opt out when making incremental hydration the default. We can also look into ways of improving tree shaking for incremental hydration.
Activity
alan-agius4 commentedon Nov 14, 2025
//cc @AndrewKushnir & @thePunderWoman
hybrist commentedon Nov 14, 2025
FWIW, I was also surprised when I tried to follow the docs about
@deferwith hydrate triggers and it "didn't work" in a new project.thePunderWoman commentedon Nov 14, 2025
It's too late for us to do this in v21, but yeah, we should enable it by default.
alan-agius4 commentedon Nov 17, 2025
Following a chat with @thePunderWoman, it was mentioned that before doing this we'd likely want to do some changes to the framework such as enable it by default make it default, not just add it in the schematic.
[-]Enable withIncrementalHydration() by default in new SSR Angular projects generated via Angular CLI[/-][+]Enable withIncrementalHydration() by default in for SSR Angular projects[/+][-]Enable withIncrementalHydration() by default in for SSR Angular projects[/-][+]Enable `withIncrementalHydration()` by default in for SSR Angular projects[/+]SkyZeroZx commentedon Mar 29, 2026
I've been testing this a bit, and I see that if we have
withIncrementalHydrationset to default, the bundle size will increase by approximately 23kb. I'm not sure if it would be worth the cost for all users, considering that there may be some who don't use it (in my case, some projects I've participated in).That said, I understand the importance. An alternative would be to perhaps have a other function / entry point?
provideIncrementalHydration(), which could be the new default for incremental hydration.And we could keep
provideClientHydrationworking as it does for those who don't need incremental hydration, as well as perhaps deprecatingwithIncrementalHydration.thePunderWoman commentedon Apr 8, 2026
@SkyZeroZx I think that
provideIncrementalHydration()defeats the purpose of having it be the default behavior. We would also provide a way to opt out when making incremental hydration the default. We can also look into ways of improving tree shaking for incremental hydration.angular-automatic-lock-bot commentedon May 10, 2026
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
This action has been performed automatically by a bot.