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.