Project Proposal: Speedy Edits (Enhancing Client-Side Performance for Librarians)

[RayBB]

Objective: A great patron experience starts with a great catalogue. Librarians make that possible. This project is to improve the experience for librarians by optimizing client-side performance through pre-caching strategies, specifically targeting areas identified as critical by the librarian community.

Background: The Open Library (OL) team is diligently working on server-side improvements, which are crucial for overall performance. However, there is an opportunity to significantly enhance the client-side experience, particularly for librarians, by leveraging service workers and pre-caching techniques. This proposal aims to address some of the most pressing issues identified by librarians, with a focus on improving load times and responsiveness.

I'd like to propose that in May I work on a small project to improve the speed of OL, specifically for librarians.

As I've worked on improving our use of service workers (#8930) I'm getting a vision for how we could improve the rest of the experience client side. It starts with a focus on librarians. I asked the librarians what they felt the most problem areas were.

Obvious candidates

A few areas we could improve with client side (pre)caching:

• Cache language autocomplete inputs/endpoints #9112
• Authors (precache edit page on author page focus) cache edit pages for librarians when on view page #9166
  • This is near and dear to my heart as I add Wikidata IDs often
• Books (precache edit page on book focus) cache edit pages for librarians when on view page #9166
  • Of course, on page focus would mean double the requests (or more), which is why I only want it for librarians for now.
    • Without going into details, it's focus because it'll be a short cache time and I think many of us open lots of new tabs and go through them one by one over time.
  • Long term, we could do something like: if a user visited any edit page in the last hour then precache the edit page on load.
• Manage covers (precache iframe on hover over edit button)
• Merge queue (precache on hover of review button, or maybe just the first one in the queue on page load?)
  • on hover may not sound like much but shaving off half a second or so for each click adds up. Try it yourself here http://instantclick.io/click-test
• Works Merge page (randomized exponential backoff for failed api calls, basically librarians shouldn't have ever refresh this page)
  • Mark has brought this up many times and I see it as a big pain point.
  • Actually, this needs a better root cause understanding. Might be due to haproxy putting people in the slow lane for too many requests. Maybe a bulk endpoint or adding ratings/reading logs would.
  • Add lazy loading for covers in works merge tool #9201
• I would like to hear more from librarians at the weekly call

Not in scope

Some things that cannot be fixed with this client side work:

• Slowness of save after editing

Why focus on librarians?

• It's just the starting point
• Starting with librarians in mind means we're less likely to add caching that is disruptive for them
• It feels less risky (not going to measurably increase load on servers)

Proposal & Constraints

A note on implementation: I think this most of these can be done extremely simply, with less than 100 lines of code that are easy to understand. No new dependencies. It may sound like a band-aid but even if OL was down to sub-second response times this will still cause the site to feel much faster.

Here's what I need:

• Feedback/approval from the staff
• A pre-scheduled code review session with staff
  • I feel this type of change is best discussed and experienced live
• A round of input from librarians in the weekly call
• A partner librarian to talk with frequently and test change
• The merging of improve service worker caching #8930 (it is a precursor to the coding)

Constraints

• I estimate that the coding of this relatively quick but review and testing longer.
• I want to use my knowledge to execute on this quickly and independently
  • (I don't want to turn this into 10 issues for different people to work on)

As always, I look forward to hearing what the staff have to say and improving the Open Library experience for everyone!

Stakeholders

[Realmbird]

Might be willing to attempt this problem