Angular Server Side Rendering Performance Analysis

The setup

Info: You can find all code samples of this blog post in our public repository on Github.

A normal Angular application renders pages in the DOM in the browser in response to user actions. Angular has a mechanism known as Change detection in place to track state changes in the application and how the DOM needs to be updated so that the developer does not have to. More information on Angular Change detection can be found here.

Angular Universal optimizes the web application load times by executing on the server - instead in the browser - generating static application pages that later get bootstrapped on the client side.

A great in depth comparison between different rendering approaches is out of the scope of this post and can be found here: Rendering on the Web.

Let's first kick-off a regular Angular application.

A regular Angular app

Initially we start with a clean ng new angular-ssr CLI command to scaffold the Angular app. This generates a new Angular web-application without any optimization in place. When we run ng serve the app is served successfully on http://localhost:4200.

To build the production version of the Angular application we need to execute

ng build -c production

This generates a production built at dist/angular-ssr:

As we are going to compare the Angular production build performance with the Angular SSR performance via Lighthouse audits we need to deploy the Angular app. For this we chose the Amazon S3 bucket service - the deployed app can be found here: http://angular-ssr-sample.s3-website.eu-central-1.amazonaws.com

Let's run the Web.dev Measurements:

Wow - amazing first results! This benchmark is pretty impressive. All major categories above 90 points. Let's see if we can beat this with Angular SSR.

Angular Universal and Server-side rendering

To enable server-side rendering in our Angular app we need to perform some basic steps (and some more advanced).

1. ng add @nguniversal/express-engine to add the Angular Universal functionality

2. npm run dev:ssr to test the Angular Universal app

3. Decide for the deployment target - we use Vercel

As Angular SSR needs - as the name already implies - some server to execute the rendering we cannot use plain object serving solutions such as Amazon S3. We need to switch to a serving solution supporting server side JavaScript execution.

1. Add a vercel.json file to the project to configure the server environment and prepare for the Angular server-side-rendering.

Json{
  "version": 2,
  "public": true,
  "name": "test-universal",
  "rewrites": [
    { "source": "/(.*)", "destination": "/api" }
  ],
  "functions": {
    "api/index.js": {
      "includeFiles": "dist/YOUR_PROJECT_NAME/browser/**"
    }
  }
}

2. Adapt the package.json to add new script targets

Json"scripts": {
    "ng": "ng",
    "start": "ng serve",
    "build-dev": "ng build",
    "watch": "ng build --watch --configuration development",
    "test": "ng test",
    "dev:ssr": "ng run angular-ssr:serve-ssr",
    "serve:ssr": "node dist/angular-ssr/server/main.js",
    "build:ssr": "ng build --configuration production && ng run angular-ssr:server",
    "prerender": "ng run angular-ssr:prerender",
    "vercel-build": "npm run build:ssr"
  },

3. Create a new api/index.js file to serve the server-side scripts. This script is pretty straight forward:

Javascriptconst server = require('../dist/angular-ssr/server/main');

module.exports = server.app();

Now the setup is ready to be deployed on Vercel - we just connected the Github repository to trigger updates and deploy changes automatically from the repository.

The deployed app can be reached at: https://angular-ssr-sample-b55z.vercel.app

Let's run the Web.dev measurements:

Very interesting! This is slightly worse performance than the production built deployed right to Amazon S3.
We will go into the details of this in our next post.

Conclusion

Whereas server-side-rendering seems to be the holy grail for optimizing apps it is not always the best solution. When you are developing Angular apps the production build already does an amazing job in optimizing the bundle size. So it depends:

• Are you integrating many third party npm packages?

• Is your app serving many different landing pages?

The answer to these questions are crucial to make the right decision when it comes to web-app optimization. Unfortunately there is no silver-bullet to optimize Angular apps - the best approach depends on the use-case.

Feel free to reproduce the measurements right here https://web.dev/measure as the results might vary slightly over time.

What's your experience when it comes to Angular app optimization? Feel free to reach out to us!