Supercharge Angular application
Let me share my real-time experience with optimizing Angular applications and how we saved 80%~ time during component rendering.
This post is going to be big so for better readability I divided this post into two parts. In the first part, I will share my learnings on Memory optimization and the second part will cover Performance optimization.
Let's start now…
It all started a few months back when I got the opportunity to start working on some challenging requirements.
Let me share those requirements here so that you can also feel the heat.
- The client wants every page of the application to be rendered with-in 90ms
- This web application will remain active and usable for 24x7 days.
Let's understand the technology ecosystem of the application, it has been built using Angular 8 and material library. In terms of 3rd party lib, loadash has been used for data manipulation.
When I joined this project they have already developed 80% of the application, the majority of the pages were getting rendered in more than 300ms. The application also becomes unresponsive after prolonged use.
Let me share the approach I used in this project to overcome all these challenges; you can also use this approach to fine-tune your frontend applications.
Let's start with Memory optimization, the first thing which I did after joining the project was to get aware of the system.
I asked multiple questions like, how many modules/components we have in the application? Are we consuming the data in real-time using websocket? Are we loading the complete application at once, or we are doing it chunk wise? What is the hierarchy level of components? I mean, are components created deeply inside other parent components?
Based on these questions I found that the application is a mid-sized application, having 100 components in 5 modules, using WebSocket to consume real-time data, it has a high loading time, and maximum pages are taking more than 300ms to render completely. The application was getting unresponsive after 3hrs of continuous use. So signs were very clear that it requires overhauling of the complete application.
I first started with Memory optimization
The best place to check the memory utilization of your web application is no more than the chrome developer tool. It helps you in recording the memory consumption of a particular page or complete functional scenario. We can also use the performance tab to see the heap memory consumed in a particular scenario.
You can observe few things in the below picture, up movement in the line suggest that we are loading/rendering a new page or a component, down line indicates that we are freeing some memory, this could be because of garbage collection run.
The point to be noticed here is, the line is not touching the x –axis, which signifies that some of the memory has not been reclaimed properly. Which suggests that there is a memory leak.
So how it should look like, ideally it should look like the below picture we have on the screen, it should demonstrate a sawtooth pattern of memory usage. We are continuously allocating memory in the application, but it is short-lived. The garbage collector periodically cleans it up and returned to where we started.
As I analyzed this pattern I straight away jumped into the code to find out the rooted piece of code which is leaking memory. I found that the application is heavily using Observables to get the external data. This Observer pattern is very handy in Angular applications. But if we don’t follow the best practice, we will fall into the memory trap.
The first big issue I found that we are not unsubscribing from the Observable when we are not in need of the data, which makes the Observable active all the time.
There are several ways to unsubscribe from observables in Angular components. One of the approaches is to use takeUntil operator. Doing this way we can unsubscribe the data service in a more functional way.
When you are working in a big team, having all the best practices written on a piece of paper would not enforce developers to use it. But with the use of linting rules, you can enforce developers to adopt the coding guidelines. I found one linting rule which helped me to adhere to this guideline with-in the team Enforce usage using linting — https://github.com/angular-extensions/lint-rules
The second issue I found that we are using event listeners in our application, we many time needs to add events on HTML elements. As these are explicitly added events listeners angular will not remove these from the system, hence you need to be careful while using it.
if you observe the above code, we are adding a scroll event on document body. Looks like whenever the user does a scroll we need to call a method this.updatePosition(). Event Code seems fine but we are not unregistering the event when we are moving out of this component. A better way to write the same code could be:
Now we have an event listener with an unregistered code block, which frees-up memory at the end of the component lifecycle.
One rule of thumb which I would recommend here is to write the unsubscribe code before writing the subscribe method.
The second rule is if there is not a data stream scenario, where you are not looking to publish or get data after some intervals, there I would like to advise Promises over Observables. I am not denying the fact that Observables are an exciting and important feature but when you are working in a big team and you need to avoid memory leaks then Promises works better as they are self closable.
After doing all the above modifications I found that the application memory consumption graph is again started touching the x-axis, this is a good sign for any web application. In the second part, I will cover my learning on runtime-performance optimization.