Web Workers — A Primer

A little of bit background on the context for this post can be found in my previous post, where I have explained on “how to achieve TTI under 4 Secs for performance optimisation, improved SEO Performance and better conversion rate”, Please have a look in the below link.

Performance

There are multiple situations in a performant webpage where increase in load time contributed by additional api calls or animations that block the Critical Rendering Path. And one has to live with it, due to the JS’s single thread architecture. Well, not any more, with the introduction of Web workers in the browsers we can achieve multi-threaded behaviour and improve the performance.

What is Web workers?

As per MDN Web Docs:-

Web Workers are a simple means for web content to run scripts in background threads. The worker thread can perform tasks without interfering with the user interface. In addition, they can perform I/O using XMLHttpRequest (although the responseXML and channel attributes are always null).

Using Web Workers

Use cases of Web Workers:

There can be multiple scenarios where you can try web worker but I would suggest to use this only when you have optimised your webpage to full extent. Please check this link for webpage performance optimization.

There are counter benefits of web workers, in case of overloading, which might cause over all improve the page load time.

Pros:-

• Main thread is not getting blocked.
• UI can respond to user interaction.
• Offload few script operation from critical rendering.
• Helps to perform more CPU intensive tasks
• It can access local storage database.

Cons:-

• Web worker file cannot access document object
• Web worker has no access to window object.
• DOM manipulations not possible.

Let’s understand the code and implementation of web worker with the help of below diagram.

As you can see in the above diagram, the main html file has a script which triggers the other web worker script and it will perform it’s task which can be any cpu intensive operation or calling external api calls etc.. During this period of time the main script is not on hold, it will continue it’s execution and also respond to user interaction on the UI.

When the web worker has completed its task, it will communicate that information and also transfer the data back to main script to apply the changes (if any ) on the UI elements based on response received from worker.

Step-by-step approach for using Web Workers:-

Check for the browser support for web worker.

1. Initialise this worker file in main script on html page.
2. Use postMessage keyword to trigger or start web worker processing.
3. Use onmessage to recieve the the input from main script.

Lets checkout our sample app:-

Html File

Web worker file.

TL;DR

https://youtu.be/ZT3z-VMxDa0

With redbus mobile web application, Web Workers have been explored at multiple places and here I am sharing the winnings for e.g.

redBus mobile HomePage Use case :-

You can see that we have multiple components on this page which can be offloaded to web worker as we have micro-service architecture, where these are being served from different api calls. We started to look into these components and started to power few of them with web worker for api calls etc..

We transferred few components to web worker for initial testing:-

• Offers components.
• Personalised experience components.(eg:- wallets etc.)

What are the benefits out of using it:-

• Better user experience for user.
• Better performance at different aspects.

Impact in terms of Total Blocking time for redBus mobileweb HomePage:-

Without web worker:-

With Web Worker:-

This data and numbers are generated from chrome Lighthouse reports

Hope, this article would have given you guys enough information for start looking for the use case in your applications.

Thanks for reading, have a great day!