{"id":26016,"date":"2025-03-23T20:15:13","date_gmt":"2025-03-23T19:15:13","guid":{"rendered":"https:\/\/www.angulararchitects.io\/blog\/complete-guide-for-server-side-rendering-ssr-in-angular\/"},"modified":"2025-04-06T08:57:05","modified_gmt":"2025-04-06T06:57:05","slug":"guide-for-ssr","status":"publish","type":"post","link":"https:\/\/www.angulararchitects.io\/en\/blog\/guide-for-ssr\/","title":{"rendered":"Updated: Guide for Server-Side Rendering (SSR) in Angular"},"content":{"rendered":"
\n\t\t\t\n\t\n\t\n\t\t

\n\t\t\tThis is post 6 of 6 in the series “Performance Optimization”<\/em>\t\t<\/p>\n\t\t\t<\/label>\n\n\t\t\t

\n\t\t\t
    \n\t\t\t\t\t\t\t\t\t
  1. Why is Initial Load Performance so Important?<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  2. How to measure Initial Load Performance<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  3. How to use Angular SSR with Hydration<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  4. Improve Initial Load Time with Deferrable Views<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  5. How to @defer 3rd party dependencies<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  6. Updated: Guide for Server-Side Rendering (SSR) in Angular<\/span><\/li>\n\t\t\t\t\t\t\t<\/ol>\n\t\t<\/div>\n\t<\/div>\n

    Updated on Mar. 23rd, 2025<\/em> for Hybrid Rendering<\/strong> & brandnew Incremental Hydration<\/strong> (now including demo) in Angular v19.2<\/em>.<\/p>\n

    This comprehensive post includes a quick introduction to SSR, a detailed setup guide and several best practices with Angular v19<\/em> (released on Nov 19th, 2024<\/em>), enhancing the initial load performance<\/strong> and thus the user experience<\/strong> of modern web applications<\/strong> built with Angular<\/em>.<\/p>\n

    If you haven't upgraded to v19 yet, then what are you waiting for? In my humble opinion, the new Hybrid Rendering<\/strong> and Incremental Hydration<\/strong> features of v19<\/em> can already be used in production, even though they are still in Developer Preview<\/em>:<\/p>\n

    \"Angular<\/p>\n

    See all Angular features in this Angular feature roadmap<\/a> by Gerome Grignon<\/a>. By the way, if you want to use Material<\/em> and\/or CDK<\/em> with SSR, you need at least v18<\/em>.<\/p>\n

    The Angular team<\/em> has recently (well actually for quite some time) been putting in a huge effort<\/a> and doing a fantastic job to help us improve the initial load time. SSR plays a significant role in achieving that goal for our framework of choice. Read my post from July 2023 to learn why initial load performance is so crucial<\/a> for your Angular<\/em> apps.<\/p>\n

    Essentials<\/h2>\n

    Let's start with the basics. You can, of course, skip this section if you're already familiar with SSR, and continue with the next section about building<\/strong>.<\/p>\n

    Server-Side Rendering (SSR)<\/h3>\n

    Server-Side Rendering (SSR) is a web development technique where the (in our case node) server generates the HTML content<\/strong> of a web page (in our case with JavaScript), providing faster initial load time. This results in a smoother user experience, especially for those on slower networks (e.g. onboard a train in \ud83c\udde9\ud83c\uddea or \ud83c\udde6\ud83c\uddf9 \u2013 which I happen to be a lot recently \ud83d\ude0f) or low-budget devices. Additionally, it improves SEO and crawlability for Social Media and other bots like the infamous ChatGPT.<\/p>\n

    New Angular CLI<\/em> projects will automatically prompt SSR (since Angular v17<\/em>):<\/p>\n

    ng new your-fancy-app-name<\/code><\/pre>\n
    For existing projects simply run the ng add<\/code> command (since Angular v17<\/em>):<\/p>\n
    ng add @angular\/ssr<\/code><\/pre>\n
    Warning<\/strong>: You might have to fix stuff manually (like adding imports of CommonJsDependencies) after adding SSR to your project \ud83d\ude2c<\/p>\n
    Follow the angular.dev guide<\/a> for detailed configuration. However, I'd recommend switching to the new Application Builder, which has SSR and SSG baked in (more on that in the build<\/strong> section below). Let's first clarify what SSG stands for.<\/p>\n
    Static Site Generation (SSG)<\/h3>\n
    Static Site Generation (SSG) or Prerendering (like the Angular framework likes to call it), is the technique where HTML pages are prerendered at build time<\/strong> and then served as static HTML when a URL is visited. Instead of rendering live on demand, SSG generates the HTML once and serves the same pre-built HTML to all users. This provides even faster load times and further improves the user experience. However, since the HTML is being stored on the server, this approach is limited whenever dynamic content is needed.<\/p>\n
    Important note<\/strong>: For the use of SSG you don't need a node.js \/ express server. You can still ship your application from nginx<\/a> or even Apache.<\/p>\n
    Full-application Hydration (preview in v16, stable since v17)<\/h3>\n
    Hydration is the process where the prerendered static HTML, generated by SSR or SSG, is enhanced with interactivity on the client side. After the initial HTML is delivered and rendered in the browser, Angular's JavaScript<\/em> takes over to "hydrate" the static content, attaching event listeners<\/strong> and thus making the page fully interactive. This approach combines the fast initial load times of SSR\/SSG with the dynamic capabilities of a SPA, again leading to a better overall user experience.<\/p>\n
    \"Angular<\/p>\n
    Before Angular's Hydration<\/em> feature, the prerendered static DOM would have been destroyed and replaced with the client-side-rendered interactive version, potentially resulting in a layout shift or a full browser window flash aka content flicker \u2013 both leading to bad results in performance tools like Lighthouse<\/strong> and WebPageTest<\/strong><\/a>. In my opinion, Angular SSR<\/em> was not production-ready until supporting Non-Destructive Hydration. This has changed in 2023 since this feature has already become stable in Angular v17<\/em>.<\/p>\n
    Please note: Since the introduction of Incremental Hydration<\/strong> in v19 (more on that later), the classic Hydration is referred to as Full-application Hydration<\/strong>. By the way, it's super easy to enable Hydration in Angular<\/em> \ud83d\udca7<\/p>\n
    export const appConfig: ApplicationConfig = {\n  providers: [\n    provideClientHydration(), \/\/ use v16 full-app hydration\n  ],\n};<\/code><\/pre>\n
    If you're still using NgModules<\/em> (for reasons), it becomes:<\/p>\n
    @NgModule({\n  providers: [provideClientHydration()],\n})\nexport class AppModule {}<\/code><\/pre>\n
    Deferrable Views (preview in v17, stable since v18) with @defer<\/h3>\n
    Deferrable Views<\/strong>, also called code>@defer<\/code<\/a> blocks, are Angular's<\/em> native primitive for declaratively defer loading components of your application. It can be used as an alternative to the router-based lazy loading through loadComponent()<\/code> (used with Standalone Components) or loadChildren()<\/code> (used with another routes definition array and formerly used with NgModules<\/code>).<\/p>\n
    The code>@defer<\/code<\/a> block allows you to specify when a component should be loaded and rendered, which can be based on various triggers like on idle<\/code>, on viewport<\/code>, on hover<\/code>, on interaction<\/code> etc. This is a great way to improve the initial load performance of your application by deferring the loading of non-critical components \u2013 for example everything below-the-fold \u2013 until they are needed. It can also be used to lazyload heavy libraries (like charts or complex tables). Learn more about the code>@defer<\/code<\/a> block in my blog post<\/a>.<\/p>\n
    Important<\/strong>: While Deferrable Views<\/strong> work completely independently of SSR, they can be used in combination with SSR to enforce client-side rendering (CSR)<\/strong> for certain components. This is especially useful for user-dependent content, such as user-specific lists or prices. The code>@defer<\/code<\/a> block will render the placeholder on the server and then load the real content in the browser once it has been triggered.<\/p>\n
    Deferrable Views Demo<\/h4>\n
    You can find a demo in the deferrable views<\/code> branch in this repository<\/a> on GitHub \ud83d\ude0f<\/p>\n
    Event Replay (in preview since v18, but battle-proven by Google)<\/h3>\n
    This example was taken from the official Angular blog<\/em><\/a>. Consider an app that contains a click button like this:<\/p>\n
    <button type="button" (click)="onClick()">Click<\/button><\/code><\/pre>\n
    Previously, the event handler (click)="onClick()"<\/code> would only be called once your application has finished Hydration in the client. With Event Replay enabled, JSAction<\/a><\/strong> is listening at the root element of the app. The library will capture events that (natively) bubble up to the root and replay them once Hydration is complete.<\/p>\n
    \"Event<\/p>\n
    If implemented, Angular<\/em> apps will stop ignoring events before Hydration is complete and allow users to interact with the page while it's still loading<\/strong>. There is no need for developers to do anything special beyond enabling this feature.<\/p>\n
    And again, it's super comfy to enable Event Replay in your app \ud83e\udd29<\/p>\n
    export const appConfig: ApplicationConfig = {\n  providers: [\n    provideClientHydration(\n      withEventReplay(), \/\/ use hydration with v18 event replay\n    ),\n  ],\n};<\/code><\/pre>\n
    Note<\/strong>: At the time of writing, this feature is still in Developer Preview, so use it cautiously. However, I believe it's perfectly ready for production usage.<\/p>\n
    Hybrid Rendering (in preview since v19)<\/h3>\n
    Angular v19<\/em> will introduce Hybrid Rendering<\/strong> to meet modern web demands following this RFC<\/a> in the Angular GitHup repo<\/em>. It allows providing additional route information for the server. Details like rendering modes and response headers will provide finer control for SSR<\/strong>.<\/p>\n
    We can now select the page rendering mode<\/strong> per route:<\/p>\n