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:
This is near and dear to my heart as I add Wikidata IDs often
[ ] Books (precache edit page on book focus) #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.
[ ] 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 #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!
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:
Not in scope
Some things that cannot be fixed with this client side work:
Why focus on librarians?
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:
Constraints
As always, I look forward to hearing what the staff have to say and improving the Open Library experience for everyone!
Stakeholders