I want to create a dashboard for my website. I have divided my dashboard into different modules. As I understand it, I will have to make many AJAX calls.

The different modules are:

  1. total number of page visits changing real-time
  2. acceptance rate
  3. denial rate, etc...

The question I am facing is: how can I minimize my AJAX calls and is there any order in which I have to place my AJAX calls while loading the page so as to achieve minimum amount of loading time?

  • 1
    You can minimize the number of Ajax calls by supporting on your server one Ajax call that retrieves all the info you need so only one roundtrip is needed to fetch all the data. If you need to share this info among completely separate modules, then you will have to make something like one central data manager which the modules will get their data from and the one central data manager will actually get the data or return the cached data. – jfriend00 Nov 19 '14 at 17:53
  • To minimize HTTP request overhead? – svidgen Nov 19 '14 at 17:53
  • yes to minimize the http request overhead and to minimze the loading time of modules. – AJAY Nov 19 '14 at 18:07
  • @jfriend00: Is there any downside to the method you suggested? What if the central data manager fails? that will mean all the ajax queries of all the modules will also fail? – AJAY Nov 19 '14 at 18:09
  • Yeah, if you have buggy code, you app won't work - all you have to do is write code that works. There's no inherent reliability issue with distributing data to different parts of your app without making separate Ajax calls. If you are implementing it like a cache, then you may need to implement cache expiration so you get fresh results when you want fresh results. – jfriend00 Nov 19 '14 at 18:11

You could build API aggregation/de-aggregation layers on both ends.

On the client-side, you can build a layer that receives API requests and "holds" them for N ms to see if up to M other requests come in. It needs to aggregate those into whatever format works for you before POSTing them. The aggregate response in whatever format is good for you will need to be split by a counterpart client layer, and the callbacks for each individual request will be issues from there.

On the server-side, you just need the corresponding de-aggregation/re-aggregation layer. Initially, you may even still process the request in a single-threaded, sequential manner. And that may even enough of a performance benefit to you. And, aggregating and "de-aggregating" requests doesn't need to be terribly complicated. You just build an array of requests and use a common serialization format (JSON) for transportation.

I've had some favorable results with a pretty simple implementation of this on a low-traffic site. (Yet to see how it scales!)

But, you may find there's no improvement at all -- you may find that, in your case, submitting N asynchronous, simultaneous-ish AJAX requests on the client-side is actually the higher-performance option. The overhead of waiting, aggregating (twice), and "de-aggregating" (twice) may be more than simply issuing multiple requests, presumably as long as those requests aren't forced to run in sequence.

  • Last sentence brings up an interesting point. If domain sharding isn't used, the XHRs and the other resources may block each other. OP might want to put domain sharding in place if it isn't yet and see if the problem goes away. – Hey Nov 19 '14 at 18:41
  • I agree with the "no improvements" warning. At one in-house app, we pass about 600 records back to the desktop. The transmission of the data, even to a remote site, just takes a couple of seconds, but the browser needs 1+ minute to parse them, update the view, etc. – SJuan76 Nov 19 '14 at 18:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.