Optimize Angular bundle size in 4 steps

pmutua profile image Philip Mutua ・3 min read

Step 1: Know your Bundle Size

It’s hard to deny that initial page loading time is tightly connected with your Angular app bundle size.
By running ng build --prod you will see the bundles size of the files the browser would get from your server

Build, Image

What size is considered good or bad?

Usually among those 4 files in the image above, only main..js is likely to go big or crazy. I checked many apps built with Angular and have a feeling that most medium size enterprise apps should have main..js under 500 KB, on average 250KB. If your bundle size largely exceed those numbers, you may need to be aware. If your bundle size is under this number, you may still want to optimize it further.

Step 2: Are your files gzipped?

Generally speaking, gzipped file has only about 20% the size of the original file, which can drastically decrease the initial load time of your app.
To check if you have gzipped your files, just open the network tab of developer console. In the “Response Headers”, if you should see “Content-Encoding: gzip”, you are good to go.

Build, Image

If you don’t see this header, your browser will load the original files. For example, for the Angular bundle in the image below, the browser will load main.0d17aff85f337483317e.js and cost 2.21MB data. However, if you gzip your file, your browser could only load 495.13KB. Such a huge reduction of file size, will obviously reduce the initial page loading time, especially when user has low internet speed.

How to gzip?

If you host your Angular app in most of the cloud platforms or CDN, you should not worry about this issue as they probably have handled this for you. However, if you have your own server (such as NodeJS + expressJS) serving your Angular app, definitely check if the files are gzipped.
The following is an example to gzip your static assets in a NodeJS + expressJS app. You can hardly imagine this dead simple middleware “compression” would reduce your bundle size from 2.21MB to 495.13KB.

const compression = require('compression')
const express = require('express')
const app = express()

Step 3: Analyze your Angular bundle

If your bundle size does get too big you may want to analyze your bundle because you may have used an inappropriate large-sized third party package or you forgot to remove some package if you are not using it anymore. Webpack has an amazing feature to give us a visual idea of the composition of a webpack bundle.

Build, Image

It’s super easy to get this graph.

  1. npm install -g webpack-bundle-analyzer

  2. In your Angular app, run ng build --stats-json (don’t use flag --prod). By enabling --stats-json you will get an additional file stats.json

  3. Finally, run webpack-bundle-analyzer path/to/your/stats.json and your browser will pop up the page at localhost:8888. Have fun with it.

Build, Image

You may be surprised,

  1. that you forgot to remove some packages you are not using anymore and/or
  2. that some packages are way larger than expected and could be replaced with another one and/or
  3. that you have improperly imported some libraries (For example, 80% of moment.js is just locale data which is probably not needed) so that you have some direction to look for an answer.

Step 4: Monitor your bundle size

In Angular 7 and later, when you generate a new app with ng new, in angular.json, you can find a configuration like:

"budgets": [
    "type": "initial",
    "maximumWarning": "2mb",
    "maximumError": "5mb"

This will give you a warning if you build Angular and the bundle size exceeds 2MB and throw an error if the bundle size exceeds 5MB. You can adjust the numbers as per your need.
You can leverage this feature in your CI/CD pipeline. If you see the warning/error, you may want to investigate what’s going wrong.

Posted on by:

pmutua profile

Philip Mutua


Currently focusing on developing server side and frontend apps


Editor guide