Transcript search responses load slowly

[elynema]

Description

With the most recent Ramp build (I think), we are seeing much slower loading of content search responses into Ramp's transcript component. In the video here, I searched for the word 'isaac' in a transcript, and you can see a noticeable delay before any results are returned, and then a series of different hit counts as searches for each letter submitted as I type are returned.

I am seeing this in both avalon-dev and on the Ramp demo site. I have seen the delay in both Chrome and Safari on desktop and also in Safari on iPad. On Android and iPhone, it seemed to behave a bit better in that it doesn't seem to return the interim results, you just have to wait a couple of seconds to get results.

Here is an example record: https://avalon-dev.dlib.indiana.edu/media_objects/gf06g267d. I've been testing by typing 'isaac' in the transcript search box for the first record.

Is there any way to speed this up, or do we need to reduce how often we send searches as the user types?

Private Zenhub Video

[elynema]

Dananji is going to make another pass on this to improve further today.

[Dananji]

In the latest PR, I removed the 5 millisecond delay in the setTimeout and now it runs without a delay. This enables the browser to schedule these requests without immediately executing them. And it helps to avoid any unnecessary UI updates for intermediate responses.

I checked the time it takes for Ramp to process the search response (UI to updates right after this).
Time difference between when the API response goes into the processing function in Ramp and when the results are formatted and passed to UI (Transcript component).

And I did this test for multiple transcripts in different items and I was seeing numbers less than 50 milliseconds (0.05 seconds) each time.

[elynema]

I checked in Chrome and Safari and on iOS and Android. I don't see the flickering of in between results, which is great. I still have to wait about .5 - 1.5 seconds before I see any results. Presumably this is a combination of the time for the content search to respond and for the results to be formatted. Per Dananji's response, it sounds like mostly time for the content search to respond.

This seems reasonable at least for first implementation, so closing this.