Optimize your Angular App using Web Workers - Digital Solutions, IT Services & Consulting - Payoda

Optimize your Angular App using Web Workers

Users always like fast and responsive web applications. They may become impatient if a web application takes more than ~3s to load and run in the browser. So, it is vital to think about optimizing the applications whenever we start developing a new web app or adding new features to the existing application. This post will discuss one of the performance optimization techniques that will make our angular application perform even better when we do any heavy computations in the User Interface.

We will be discussing Web Workers, which will be helping us to optimize our angular application by running the heavy computational task in a separate worker thread by freeing up the main UI DOM thread which will be running to update the UI and other runs low computational scripts.

What is a thread?

The main thread or a DOM thread is the one used by the browser to handle user events, render and run the majority of the code that comprises a typical web page or app. Because everything happens in a single thread, it will slow down the browser if we perform any huge computations. So, the huge computations should run in a separate independent worker thread.

Types of Web Workers

All the above workers come under the context of Web Workers and do the same thing but execute different functions. A similar thing they do is create a parallel thread. Worker threads run in a different environment where DOM-related APIs will not be present. So, Workers will not have access to the DOM API’s.

Web Workers can access Cache, setTimeout, setInterval, clear interval, clearTimeout, atob, btoa, navigator, and location. Web Workers are just the script file where we can write code to perform heavy load tasks. We can make the script file as a Web Worker by writing the below code.

In the above code, the JS file is passed to Worker to instantiate(install) it. The Worker API will create a new thread by allocating a certain memory space. CPU will then run both DOM thread and Worker thread parallelly (activation). We can kill the worker thread by calling webWorker.terminate().

The Lifecycle of Web Worker


This is triggered when a message is received from the Worker thread to DOM.


This is triggered when an error is thrown inside Web Worker.

From DOM to Worker Thread

From Worker Thread to DOM

Listen for messages from DOM in Worker Thread

Adding Web Worker to Angular

It may look like Web Workers can be used only in Vanilla JS apps. But, angular also provides a dedicated cli command to generate web worker files and configuration files to configure settings for web workers. After V8 of angular, code splitting, bundling, and setup using Angular CLI was made easy.

To add a web worker in the angular project, run the below command:

Imagine, if we run the prime number logic for the largest number in the DOM thread instead of the Worker thread. It will eventually make the DOM thread to run slow and drag the User Interface. So, by running prime number logic in a separate worker thread, we are making sure that the DOM thread is not locked and becoming unresponsive.

In our app.component.ts file, add the below code

In our app.component.html add the below code

Now run the angular project by issuing the ng serve command and open the application in localhost:4200 to see the below output.

We are able to see the list of prime numbers generated by the Worker thread and passed on to the DOM thread for the provided input. During the process of finding prime numbers, the DOM thread would focus on user interactions and let the worker thread take care of providing prime numbers.


On the browser, the physical presence of the Worker instance can be found below.

To measure the performance of the application in the presence of Web Worker, we can use the performance and lighthouse tool present in the browser to get the audited reports.

Final thoughts

In the above post, we saw what Web Worker is and its types. Using Web Worker, we can offload the heavy work to the Worker thread rather than running it in a DOM thread and making the UI completely unresponsive. Operational time will be the same in both DOM thread and Worker thread, but what really matters is we should run only lightweight javascript code in DOM thread in order to not block UI for users for a very long time. Performance matters in real user-friendly applications.

Leave a Reply

Your email address will not be published. Required fields are marked *

sixteen − seven =