We make 3 to 5 requests per image depending on circumstances (3 should be much more common). Image data loading is queued, so we fire of the first batch of requests for the current image, wait until all of those have been finished, fire the requests for the next image, wait again, fire the requests for the image preceding the current one. Thus the connection limits are not exceeded (on modern browsers anyway).

 

It should be fairly easy as long as we are talking about merging all the API requests for the same image. Merging all the requests for all images (i.e. loading all the data for 3 images in a single request) would be more complicated, but it is probably less useful for comparison anyway - as I said, the current code does not make all those requests in parallel.

While we are speaking about controlled experiments, would it be possible to perform some sort of load test with some sort of script generating API requests, instead of waiting until we find out server-side performance problems the hard way? Changing the pattern of requests in a text file is much easier than doing it in live JS code that actually relies on those requests; and while it would not answer questions about client-side performance effect, it would be probably more useful for estimating effects on server load than any live experiment we could be doing with MediaViewer in its current, relatively low-traffic state.

We might want to do a similar test with image requests as well, to check the load on scalers, given that MediaViewer is requesting sizes that were typically not used before.