Viewer Overlay Performance Bugs

[miqrogroove]

I've been troubleshooting the bandwidth-hungry demands of the CollectiveAccess 1.7 image viewer overlays. They become more and more noticeable when using remote or mobile connections with limited connection quality. I will write a few separate issues and use this ticket to describe the overall problem.

Bug 1: Failure to provide appropriate Cache-Control header within the IIIF service. The need for this arises from the different viewers employing a large number of asynchronous image requests without implementing error handling. If one or more of those requests does not complete within the timeout period, the display will not recover. Without client-side caching, the web browser will not resume upon refresh. In fact, the browser must repeat every request for every tile, even if the user has merely closed and reopened the overlay without refreshing the page. This still becomes problematic even if there are no errors because it slows down rendering tremendously compared to retrieving tiles from disk cache.

Bug 2: jQuery cache busting used when loading the overlay resources. For example, on every click of a thumbnail for the Mirador viewer, the browser is required to perform an ajax request for a half megabyte file named mirador.js. This causes an unnecessary delay in rendering even on faster connections. The Universal viewer implementation doesn't seem to have the same bug.

Bug 3: Lack of error handling within the viewers. This problem might be an upstream vendor issue. If the viewer doesn't provide a retry callback for a tile request that errors out, then only some of the tiles load on a slow connection. The missing tiles stay in a failed state, even when zooming.

[collectiveaccess]

Thanks for this. We'll look into applying these findings for the next release.