The 4 Stages of Perf Tuning for your Angular2 App
tl;dr
Angular2 was built from the ground up with the primary goal of being fast and performant. While being fast right out of the box, the performance of Angular apps can be further enhanced really supercharge your app. These performance enhancements can be see as a pyramid where each level improves a certain performance metric.
Let’s look at each of these and how do they go about improving your app’s performance.
1. Ahead of Time (AoT) compilation and Tree Shake
AoT is one of coolest feature of Angular2 that differentiates it from other frameworks and also the one that gives you the biggest performance boost.
To compile your app using AoT you would use the ngc compiler that will convert your component, HTML templates and the CSS into a chunk of code that Angular bootstrap can directly render without having to compile it in real time like the way it currently does.
Using the AoT compiler can help cut down your bundle size by over 50% and improve first paint by over 45%.
This is mainly due to the fact that the JIT compiler (which is ~50% size of the Angular library) is no longer needed with AoT.
Tree Shake
Tree shake is the process of removing unused modules and code from your app before it is finally bundled and minified.
As it turns out Tree Shake is different from dead code elimination.
This process depends on ES2015 modules. One can use the Rollup.js or Google Closure Compiler to carry out tree shake of the AoT compiled code to further drop your bundle size.
You can achieve close to 2.5x reduction in your bundle size using AoT and Tree Shake.
Here is a nice and easy to follow cookbook on performing AoT and Treeshake for your angular app.
2. Angular Universal
Angular Universal allows you to run your Angular App on the server.
Using Universal helps improve the rendering performance for first time visitors as the first view is generated by the server as soon as a page is requested and the angular client size library downloads in the background.
One of the challenges of Universally rendered or hydrated apps is the problem of the Uncanny Valley.
Angular Universal tries to solve this problem a small library called preboot.js which tries to solve the problem of the uncanny valley by recording and replaying the events when while the user is in the ‘uncanny valley’ zone. Once the client side app has bootstrapped the state is seamlessly transferred to the clientside.
3. Web Workers
Web Workers are great to offload your CPU intensive tasks to an independent web worker thread so that the frontend UI is not frozen or Janky when the app is fetching and processing large amounts of data.
Angular allows us to run the entire application in a web worker and communicate with the frontend using MessageBrokers.
4. Service Workers & PWA
Service workers offer instant loading and offline capabilities for your application. Adding a service worker and a web app manifest file to application is very easy using Angular CLI. All you need to do is pass the — mobile flag and Angular CLI will automatically add the service worker and the manifest file to the application it builds.
The Progressive Web App is essentially a collection of a couple of principles and guidelines that allow for an enhanced user experience on mobile device. Angular apps can be easily converted into a PWA by mapping each of these PWA guidelines to an Angular feature as described below.
Using Service workers and the App Shell model you can get your first render times to under 200 ms.
Summarizing
- Ahead of Time (AoT) +Tree Shake: This should be done for much most of your application there is no real reason why you shouldn’t be doing it.
- Universal Rendering: Again something that should be done for most applications however they become predominantly important when you have a lot of first time users, where SEO is crucial and where people generally share a lot of your content on social media.
- Web Workers: In case you are building large dashboard with lots of number crunching and data visualization happening in your Angular app, resort to using Web workers to ensure that users are able to continue interacting with our app while the data is being computed.
- Service Workers: When building a mobile first app, which needs to support things like instant loading, offline support and running in full screen mode.
