Thumbnails Load Slowly in Search Results

[joncameron]

Description

Thumbnail images load very slowly. This is likely due to each thumbnail image requiring a separate network request to pull the thumbnail image data from Solr.

The thumbnail image data could be returned in the original Solr search request, but it is not currently because it is in a separate document that would have to be joined. Unknown if that would negatively impact performance loading results from the search itself. We would not want to delay the loading of the search result response itself; even 1-2 seconds in delay would be undesirable and we wouldn't want to make this change.

Another option to explore would be caching the thumbnail images or perhaps storing them on disk somewhere.

Done Looks Like

• explore returning thumbnail image from data to see impact on search response time

[elynema]

Probably good to test this out on mco-staging since that is where we have significant dataset to work with.

[masaball]

I did not end up doing any benchmarking for this on mco-staging yet because the method I used to get thumbnails returned in the Solr document requires a reindex of all of the IndexedFile objects. However, I was able to get a proof of concept working locally. I did not notice any degradation of search times on my small local repo (< 25 items), but that is not surprising. It will be interesting to see how it fairs with a large dataset.

In terms of the thumbnail generation itself, times were drastically improved. The old method of requesting the thumbnail can take as much as 1 second per request. The requests are able to run concurrently so the overall page load time is not drastically affected, but there can be noticeable lag between initial page load and thumbnails populating, as well as noticeable lag between each individual thumbnail populating.

With the thumbnail data being returned from solr and inserted directly on the page, there is no lag. The thumbnails are populated as part of the initial page load. On a page load when assets have been cached, this reduces the page load time by about 0.3s. Page load time for a full refresh (cleared cache) was not appreciably/consistently better or worse.

The possible exception to improved thumbnail loading are items that do not have thumbnails. I have not reworked that path to try direct insertion of the icon image so they still use the asset_path in the image tag. You can see in the video below that the third item is an audio file. The first couple reloads are regular reloads, so the icon is cached and immediately displays. However on the third reload I did a shift-reload and it had to request the icon again, where there was a noticeable lag. So that would be a good improvement on the proof of concept is to see if there is a way to easily add the icons to non-thumbnailed items.

Private Zenhub Video

[masaball]

WIP: #6032

[elynema]

Blacklight is caching something, but not sure if it is the img tag or the image itself. All thumbnails are also loaded after all the other assets (JS, CSS), which delays them. Potential speedup would be to force JS to load after thumbnails, but that might break other things?

Leaning away from original test implementation / PoC because loading base64 encoded bytestring of image into img tag is a discouraged code pattern.

Besides better way to cache stuff, the last suggestion was moving thumbnails out of Fedora and to disk. That option hasn't been explored yet. similar process to moving captions to ActiveStorage; adding another allowable supplemental file tag or type and re-doing the endpoints to point to the new setup and run a migration task.

Rather than running a big migration, could we somehow cache the thumbnails on disk to make things faster?

[joncameron]

Closing the PR in favor of more conversation: #6032.

See #6032 (review)