Fastest way to request many resources via Ajax to the same HTTP/2 server

Question

Thanks to HTTP/2's one connection per origin principle, the browser can load many resources in parallel when a web page loads (scripts, images, etc.), but how should a script do the same thing dynamically?

For example, if a script creates 5 XHR objects and makes parallel calls to the same server, will they all reuse the same TCP connection? What if the script needs to request 100 resources from the same server via Ajax? Should it create 100 separate XHR objects or should it create a small amount and reuse them each time a request completes? If so, how many is optimal in the era of HTTP/2?

In general, it's hard to find the low-level details about exactly what browsers are doing with HTTP/2 when it comes to XHR (and the newer Fetch API) and exactly what is the best way to do what the browser does on page load, ie load dozens of small resources as quickly as possible.

Taenia

Answer 1

For example, if a script creates 5 XHR objects and makes parallel calls to the same server, will they all reuse the same TCP connection?

If the browser and server both support HTTP/2 then yes they will do this automatically without you having to make any changes to your JavaScript. That's one of the great things about how HTTP/2 has been implemented.

There are some scenarios where it will not use a single connection e.g. uncredentialled connections go over another connection, and currently web sockets fall back to HTTP/1.1 (through a way to do that over HTTP/2 is just being standardised). Also some browsers reuse connections across tabs, some do not. But in general it should use the same connection.

What if the script needs to request 100 resources from the same server via Ajax? Should it create 100 separate XHR objects or should it create a small amount and reuse them each time a request completes?

You can send 100 requests. Servers usually have limits (100 to 120 are common) and you can create download contention when sending so many requests so might be better doing fewer. Chrome also found performance issues when sending so many requests and so deliberately limited some under HTTP/2 so watch out for that sort of thing. More details here: Google Chrome does not do multiplexing with http2

If so, how many is optimal in the era of HTTP/2?

A very interesting question - for which there is no quick answer!

In general, it's hard to find the low-level details about exactly what browsers are doing with HTTP/2 when it comes to XHR (and the newer Fetch API) and exactly what is the best way to do what the browser does on page load, ie load dozens of small resources as quickly as possible.

Agreed. And, since HTTP/2 is still relatively new, this is also still changing quite a bit. Best is to familiarise yourself with HTTP/2 as much as possible and test, test, test!

Mathematical

Thanks Barry, good to know browsers do reuse automatically. Do you know if the browser holds onto the connection after a request completes, e.g. for a few seconds, in case a new request occurs? Since we can't create infinite XHRs, it's a possible scenario where the connection might fail to be reused and if not handled right by the browser, could still cause many new TCP connections. – Taenia

The specification (httpwg.org/specs/rfc7540.html#rfc.section.9.1) states "HTTP/2 connections are persistent. For best performance, it is expected that clients will not close connections until it is determined that no further communication with a server is necessary (for example, when a user navigates away from a particular web page) or until the server closes the connection." From what I've seen most browsers seem to abide by this, though usually a server will reset the connection after 60 seconds of inactivity (like they do under HTTP/1.1). The browser will reconnect if it needs to. – Mathematical