Secrets of Javascript: Web Workers

Web workers provide the opportunity to run code on a separate thread outside of the main JavaScript thread. Each Web Worker is initialized by referencing a script file and, turns out, they’re super easy to set up:

{https://gist.github.com/leofab86/09a9d539dda34506c37a9ad74487404b#file-searchresults-js}

and here is that webWorker.js script that was initialized in the SearchResults constructor:

{https://gist.github.com/leofab86/df4bf9c697a95c800f40c38a2478ed2d#file-webworker-js}

I’m now starting to add in some bells and whistles. In this case, I added a cache to instantly respond to previously used searchTerms, which should have the effect of making the most demanding user interaction, holding delete, the most efficient one.

Lets see this bad boy in action:

View post on imgur.com

Holy smokes… That’s fast! At this point this is looking really nice and, to be honest, we could probably ship it and call it a day.

But, that’s no fun…

In terms of user experience, this UI is almost as good as it gets. If you pay close attention, you can still see the delay of the search results, but it is fast enough where it can be difficult to notice. Fortunately, we can look to the performance profile to spot inefficiencies:

 

In this profile, on the left, you can see which thread we are focused on. The Main thread is minimized because it is full of empty space, meaning it is performing well and would not be the source of any meaningful performance bottleneck.

You can see the Worker thread, on the other hand, piling up search calls and the effect of this after the blue line, which is the last Key Character input. The final search in the Worker thread actually returns its results three searches later. If you measure that delay it comes out to about 850ms. And, most of that is unnecessary work because three of those searches are stale, meaning they are returning results for searches that we are no longer waiting for.

You may be thinking, “Oh cmon, it’s good enough, this isn’t an efficient use of our time!”

I disagree. For one, don’t underestimate the value of trying new things and exploration. If you’ve never done this before you can’t effectively measure whether it is worth it or not because you can’t fully understand what you stand to gain and how much time and effort it will take. Even if this turns out to be an unnecessary optimization, the experience and knowledge that comes with these playful explorations is priceless. Going forward, you will be in a much better position to evaluate effectively whether this was time well spent and whether you should worry about stuff like this in the future. You are arming yourself to make better decisions down the line!

Second, remember this isn’t premature optimization. We are responding to performance profiles where we can measure our gains. An 850ms delay is very significant by any measure if we can do something about it.

Last but not least, don’t forget about mobile! When I went through this myself I was also tracking mobile performance and there was still noticeably unpleasant performance lag at this stage.

Anyways, lets get on with it! How can we make this better?

Stay tuned…

 

More News

| 12th Aug 2019

Why Isobar Uses, Supports, and Creates Free and Open Source Software

Technical director Craig Andrews explores how FOSS improves Isobar’s value proposition.

| 2nd Aug 2019

Secrets of JavaScript: The Solution

In part four of our latest series, Secrets of JavaScript, Leo takes a look at multi-threading

| 17th Jul 2019

Secrets of JavaScript: v1.1.0 Async Rendering

In part three of our latest series, Secrets of JavaScript, Leo takes a look at async rendering.