Server-side rendering in Angular 16 and beyond

Editor’s note: This article was reviewed for accuracy by Oyinkansola Awosan on 15 May 2024 and updated to include information about Angular 17, expand on use cases and benefits of Angular SSR, discuss common issues when working with Angular SSR and their potential solutions, update the comparison with SSR in React, and add a comparison to SSR in Vue. Some of the information in this article may still be outdated with regard to the latest version of Angular.

Angular introduced non-destructive hydration for server-side rendering (SSR) in its v16 release in May 2023, marking a significant milestone for Angular developers. In the v17 release, non-destructive hydration became the default with the introduction of the new @angular ssr package.

In this article, we will explore SSR and compare Angular’s SSR with React’s SSR. But before we delve into Angular SSR, let’s take a look at client-side rendering (CSR) and server-side rendering in the context of a single-page app (SPA).

CSR vs. SSR

In SPAs using CSR, the client app generates HTML within the browser using JavaScript. When the client app sends an initial request, the web server responds with a minimal HTML file to serve as the app container. The browser then downloads and executes the JavaScript bundlers referenced in the HTML file to bootstrap the app.

CSR has a few disadvantages, including:

• Blank page in initial load time: There is a delay before the JavaScript bundle is downloaded and the app is fully bootstrapped. During this time, users may see a blank page, which may impact UX
• Non-SEO friendly: Webpages relying on CSR mostly contain minimal HTML with links to the JavaScript bundle, so web crawlers may have difficulty in indexing the page content, which may result in reduced visibility in search engine results

SSR, however, addresses both the blank page issue and SEO concerns.

Using SSR, the HTML is generated on the server side, so the generated pages are fully formed and SEO-friendly. Its load time is also faster for the initial request, as the HTML is returned to the browser and displayed before JavaScript bundles are downloaded.

Thus, when SEO and initial load time are priorities, SSR is the recommended option.

SSR with Angular 4 and Universal

In v16, Angular supports SSR through its Angular Universal package, a nickname for server-side rendering in Angular that refers to its ability to render at both the client and server sides.

First introduced in Angular 4, Angular Universal provides server-side rendering, including dynamic server rendering as well as static pre-rendering. However, this form of SSR had a few limitations due to its “destructive” nature.

To better understand how Angular Universal works, we need to look at the concept of hydration.

In v17, Angular supports SSR directly as Angular Universal is replaced by the @angular ssr package. This package provides the core functionality for rendering Angular applications on the server, thus making Angular Universal outdated.

Angular’s destructive hydration

Angular hydration is the process of adding interactivity to a server-side rendered HTML page by adding event listeners and states. Efficient hydration is critical to user experience, but it is also challenging to implement as there are many moving parts to manage.

Before Angular 16, the hydration process in Angular Universal was destructive hydration. When a pre-Angular 16 app starts, the following events take place:

1. The browser sends a request to a web server
2. The web server immediately returns the DOM structure markup of the webpage
3. The browser renders the initial version of the page markup, but it isn’t interactive yet, as the JavaScript hasn’t loaded
4. The JavaScript bundles are downloaded in the browser
5. The Angular client app takes over, loads the bundle, and is bootstrapped
6. The whole page is reloaded

The above process is called destructive hydration because the client app discards the pre-rendered HTML and reloads the entire page.

It is worth noting that in step 3, the page displays some content known as the First Meaningful Paint (FMP). A quicker FMP is one of the primary benefits of SSR, particularly for performance-critical apps.

The problem of destructive hydration is page flickering, which happens when the server-side-rendered markup is replaced by the client-side rendered content. Multiple issues (i.e., 13446) have been opened in the Angular GitHub repo to resolve this, and it’s considered a main limitation of Angular Universal.

Angular 16: Non-destructive hydration

Angular 16 solves this problem by the introduction of non-destructive hydration.

In non-destructive hydration, existing server-side-rendered DOM markup is reused. That means the server-side-rendered DOM markup isn’t destroyed; instead, Angular will traverse through the DOM structure, attach the event listeners, and bind the data to complete rendering.

Below is a comparison diagram to illustrate the difference between destructive and non-destructive hydration:

Another related improvement is that HttpClient has been updated to enable server-side request caching. This enhancement prevents redundant data retrieval on the client side by caching previously fetched data, resulting in better performance.

Applying SSR to an existing Angular app

In Angular 16, Angular Universal provided more streamlined tooling support.

Assuming you have an existing Angular app, we just need to run the following command to enable server-side rendering:

ng add @nguniversal/express-engine

However, in Angular 17, Angular Universal was renamed to Angular SSR and is now built into Angular, effectively streamlining the process of enabling SSR in new and old projects. For existing projects, you only need to run the code below to enable SSR:

ng add @angular/ssr

This command will update your app to add a server-side application for SSR support and is unlike the Angular 16 update that enabled SSR using Angular Universal.

Non-destructive Hydration in Angular 16 & 17

To enable non-destructive hydration in Angular 16, we need to import the provideClientHydration function as the provider of AppModule:

import {provideClientHydration} from '@angular/platform-browser';
// ...

@NgModule({
 // ...
 providers: [ provideClientHydration() ],  // add this line
 bootstrap: [ AppComponent ]
})
export class AppModule {
 // ...
}

If you open package.json, you will find a few new commands were added:

   "dev:ssr": "ng run angularSSR:serve-ssr",
   "serve:ssr": "node dist/angularSSR/server/main.js",
   "build:ssr": "ng build && ng run angularSSR:server",
   "prerender": "ng run angularSSR:prerender"

To test server-side rendering in your local, run this command:

npm run dev:ssr

The app is running in SSR mode now!

It is important to note that in Angular 17, non-destructive hydration is a built-in feature, so there is no additional code specifically needed to enable it. It is the default behavior when using the @angular/ssr package and building for SSR.

Partial hydration

Partial hydration is when parts of the component tree are skipped during initial rendering, and hydrated later by user demand. This is in contrast to full hydration, where all the components in the page are rendered at once.

Partial hydration in Angular will be an exciting enhancement to the existing SSR approach, as it enhances performance and responsiveness to a greater extent.

Resumability

To understand resumability, let’s look at the problem it tries to solve. In the hydration process, there is a period called the “Uncanny Valley”. As shown in the diagram below, the uncanny valley occurs when the page is rendered but is not interactive:

The page will become interactive after all of the event handlers and application states are restored for the whole component tree. In the uncanny valley period, if the user tries to click a button or scroll the page, nothing will happen.

Resumability resolves this issue by serializing event handlers and state on the server and resuming it on the client on demand.

For a resumable Angular app, if a user clicks on a button in the uncanny valley period, the button event handler will be downloaded directly and executed in the browser. It does this without needing to download all the JavaScript bundles and walk through the whole component tree.

Although resumability is a great improvement, it is a complex feature to implement and may introduce additional constraints for developer experience. The Angular team indicates that they are exploring the direction of leveraging Angular’s new Signals feature to provide a solution.

Angular SSR is becoming more modern and powerful. But how does it compare with React?

SSR in Angular vs. React vs. Vue

Angular’s non-destructive hydration works in a similar way to React SSR. React provides a server-side API to render React components to HTML on the server. The React client app will receive those HTML files and make the app interactive by attaching event handlers and states. This process is called React hydration.

The implementation of React SSR with pure React is a very manual process. You need to implement a server-side app, make changes to client-side components, and manage extensive configuration changes.

In contrast, the implementation of Angular SSR in Angular 17 and beyond is very straightforward, formally part of the Angular framework, and provides much more streamlined tools to support SSR.

Using Next.js makes it much easier to support SSR in React, just as using Nuxt.js makes SSR easier in Vue. Below is a summary of Angular’s SSR features compared with that of React and Vue.js:

Feature	Angular SSR	React + Next.js	Vue + Nuxt.js
Rendering strategy	Supports CSR, SSR, and SSG (or pre-rendering)	Supports CSR, SSR, and SSG (or pre-rendering)	Supports SSR, SSG, and CSR (or pre-rendering).
Pre-rendering	Supports SSG for the whole or part of a site, as well as generating pages with dynamic routes	Supports SSG for the whole or part of a site, as well as generating pages with dynamic routes	Supports SSG for the whole or part of a site, as well as generating pages with dynamic routes
Incremental static regeneration (ISR)	No out-of-the-box support, but offers a third-party library called ngx-isr	Supports ISR out of the box	Not offered or supported out-of-the-box.
Mixing SSR and SSG	You need to write custom coded in server.ts to manage routes	Allows you to choose SSR or SSG on a page-by-page basis	Allows you to choose SSR or SSG on a page-by-page basis
Ideal for…	..large websites where high performance and SEO is a top priority as pre-rendering enables search engines to index content easily. Also great for applications with strong architectural and state management needs.	..complex, dynamic SPAs where SEO, performance optimization is priortized as React is great for managing complex interfaces. Also great for projects where SEO, customization, and API integration is important.	..content-heavy applications, e-commerce websites due to Nuxt.js support for generating static sites. Also great for projects with focus on SEO as Nuxt.js SSR ensures content is easily indexed.

In summary, not only does Angular SSR offer great features similar to what Next.js + React and Vue + Nuxt.js offer, it’s also the only built-in one, making it a better option where SSR is concerned.

Beyond SSR: Significant Angular features in v16 and v17

Angular 16 introduced many new features, including reactivity, SSR, and tooling updates.

Besides SSR, another heavyweight feature is signals, a new way to manage state changes that is much more intuitive and simple to use. Since signals allow developers to run change detection in specific components, they significantly improve runtime performance.

Other new features in the releases include:

• Required component input
• Automatic route params mapping
• New DestroyRef injector
• An esbuild dev server
• Dependency injection debugging APIs
• Improved documentation and schematics for standalone components
• Support for Tailwind CSS and CSS isolation
• Improved security and prevention of XSS attacks

Angular 16 made big improvements in application performance and UX. According to the Angular team, the Largest Contentful Paint (LCP) performance has improved by up to 45 percent using the enhanced SSR.

Angular 17 was released in December 2023 and it came with some amazing new features, like:

• Improved SSR
• Deferrable views
• Support for TypeScript 5.2
• Built-in control flow

One of the top requests from the Angular community was for better SSR integration, and Angular 17 answered that. The team greatly improved SSR by introducing the new @angular/ssr package, which simplifies SSR setup and integration into Angular projects.

Also, Angular‘s continued efforts to keep up with new TypeScript versions means better type checking, type safety, and overall experience when working with both tools.

Common issues and solutions when working with Angular SSR

While Angular’s SSR integration has seen many improvements, there are still some common issues that developers encounter. Let’s see an explanation of some of these issues and their potential solutions:

Server-side data fetching

Some components may depend on data fetched through HTTP requests on the client-side, which means the data won’t be available on the server during SSR, leading to errors or incomplete rendering. Fetching data on the server-side can also lead to delays in page loading.

The solution here is to pre-fetch the data on the server before rendering. This results in faster page loads, reduces client-side requests and even allows the server to handle the initial request(s) better.

Hydration and rehydration errors

Hydration and rehydration errors happen when the HTML generated by the server doesn’t match what the client-side expects. This then leads to inconsistencies and can cause issues in making the page interactive.

To solve this issue, use browser developer tools to inspect the DOM and identify any discrepancies between the server-rendered HTML and the actual client-side structure. Also, ensure data is being fetched consistently to synchronize data between server and client, and verify browser compatibility and correct SSR configurations.

Lazy loading/routing

Lazy loaded modules may cause some delays in SSR if custom preloading strategies are not implemented correctly thus resulting in slower load time. Delays may also occur during initial loads if they are not preloaded, and a request needs to be made to the server.

There are various ways to go about a solution for this. Using resolvers which will load data only when needed may be helpful. It could also help to preload downloads and cache associated routes that may be needed.

Implementing proper preloading strategies and importing PreloadAllModules can greatly help in preloading lazy-loaded routes and reducing load time, like in the example below:

import { NgModule } from '@angular/core';
import { RouterModule, Routes, PreloadAllModules } from '@angular/router';

Conclusion

While Angular 16 is a groundbreaking release, Angular 17 answers some urgent requests from the Angular developer community, making it an equally important release. The new SSR package makes integrations much easier, delivers significantly better performance, and sets the stage for further improvement.

As Angular continues to evolve, developers can look forward to a better development experience in 2024 and beyond.