CODEWITHSUNDEEP
javascripthtmlperformancegraphqlweb-worker
xiGUAwanOU
xiGUAwanOU

Reputation: 334

JavaScript event handling performance with many asynchronous HTTP calls

TL,DR;

The full story can be summarized into following questions:

  1. how can I keep a good performance while doing a lot of dynamic asynchronous HTTP calls in a web page?
  2. is GraphQL or WebWorker a good way to go?

Full Story

I have a SPA CMS project where the dynamic data are coming from a number of different sources. As a result, to show a table containing a lot of data, the page needs to generate a huge number of HTTP calls.

What I've tried is to make all the HTTP calls asynchronous and once one of the HTTP calls returns, the corresponding cell in the table will be updated accordingly. And I'm sure that none of the HTTP calls are made in a synchronized way because of bug or carelessness.

However, there are still performance issues. When a large number of HTTP calls resolves in a short time range, the page rendering becomes a problem. Once a user is trying to perform interactions, e.g. mouse-scrolling, etc., between two user input events, there are a lot of resolved HTTP call events. Although each re-render callback won't take much time, they are still causing performance issues if all the small time-slices are summed up.

I'm currently considering two possible solutions:

  1. implement GraphQL in a gateway service, to reduce the number of queries in total, or
  2. implement WebWorker to batch resolved HTTP calls, thus reducing the number of rendering callbacks in the main thread.

The GraphQL solution requires a lot of re-work, which is what I'm trying to avoid. But I don't have much experience with WebWorker, will it work as intended? And are there any other solutions?

Btw., for rendering table, I'm using Element UI table component. And the browser compatibility is not a problem for me.

Upvotes: 3

Views: 109

Answers (1)

T.J. Crowder
T.J. Crowder

Reputation: 1074989

Minimizing the number of discrete HTTP calls is a good idea, so #1 or similar is something you should be looking at medium- to long-term.

Re #2, though, you probably don't need to use a web worker for it. Processing the completions probably isn't the bottleneck, it's more likely all the little DOM manipulations causing lots of reflows and similar. So if you batch them up and apply a batch of them at once, you should be able to markedly reduce the impact of those changes without having to use a web worker to do it.

Upvotes: 1

Related Questions