Optimize annotation load time #566
Description
Context
As-is, annotations can be slow -- a few seconds at times. So we may want to look into ways of speeding up annotation loading.
Some ideas
1. Pure Database Optimization
At a basic level, how our queries run could probably be improved. We could drill down and investigate which parts of our existing queries are most expensive and resolve them (for example, a join where we might only need a SELECT EXISTS statement).
2. Pre-load next annotation
Currently, the backend logic submits the prior annotation before loading the next annotation. However, we could pre-empt what the next annotation would be after the current one and start loading that before the user is done with the current annotation.
3. Cache recently loaded results
For requests which have recently been pulled, we could cache some or all of the response and use that cached result when sending the response.
We'd have to think carefully about how we'd do this, since we'd have to contend with stale data. For example, if user A sends an annotation for URL 1, then a cached response might lead user B not to see the annotation of user A.
4. Partial Annotation Loading
On the backend, the single GET request for an annotation is broken down into multiple database requests, simply because there are so many elements to a single URL that it would be cumbersome and error-prone to load them all in a single query.
We already do this partially -- the screenshot for a URL is independently loaded.
This breaks down into two sub-approaches:
a. Selectively load annotation components based on prior choices
If a user identifies a URL as Not Relevant, then all annotations for Location, Agency, Record Type, and Name don't need to be presented, because the user won't see them. But currently, we will load all those components regardless of whether the user's choice would lead to them being seen. If we're willing to delay loading until we know what the user selects, we may save retrieving some data.
b. Delay loading annotation components.
Even if all annotations would be relevant to a user, they would not see them all at once. In the case of the URL Type path, they would have to pick a location, then an agency, then a record type, then a name. That means we could space out requests for just these annotations to occur slowly over time, privileging the annotations the user would see earlier. This would mean more API requests, but the same number of database requests. It makes it more likely for the user to see something faster, but may not see everything at the start.
Requirements
- pre-load the next annotation once the current one has loaded
- no matter how fast we make this, nothing will be faster than "pre-loaded"
- optional: implement other enhancements
- I'm not really in favor of increasing the number of API calls