Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Laggy / slow gallery (large libraries — sometimes) #41

Closed
joonaspaakko opened this issue Apr 5, 2021 · 3 comments
Closed

Laggy / slow gallery (large libraries — sometimes) #41

joonaspaakko opened this issue Apr 5, 2021 · 3 comments
Labels
bug Something isn't working

Comments

@joonaspaakko
Copy link
Owner

joonaspaakko commented Apr 5, 2021

It depends on what kind of computer you are using. You could see it happening on an old laptop or perhaps you don't see it at all. I'm seeing this on slightly older mobile devices when the library exceeds about 600 books.

It also depends on the size of the current list. As in if you filter your library to let's say 200-400 books, you probably won't see the issue.

It basically lags when you do anything:

  • Scrolling
  • Loading elements after scrolling
  • Opening book details
  • Everything just kind of takes its time
  • The more books you add, the laggier it gets

Proposed fix:

Currently, there's basically a kind of a pseudo lazy load that keeps track of every single book's position and then renders rest of the information when the books enter the viewport on scroll. So the solution I'm going for is to further the same idea by loading books in chunks so the original solution doesn't have to keep track of so many books at once. Note: the position tracking ends when the book is fully rendered. This solution doesn't affect the initial page load time.

@joonaspaakko joonaspaakko added the bug Something isn't working label Apr 5, 2021
@JKamsker
Copy link

JKamsker commented Apr 7, 2021

Maybe even split up the json into chunks, so that the browser doesnt have to parse gigabytes of metadata at once :D

@joonaspaakko
Copy link
Owner Author

joonaspaakko commented Apr 7, 2021

It would be ideal to load the books in chunks to reduce the initial page load time, but I'm not sure if I'll ever be ready to do that at this point as I hadn't considered it in the beginning and it would require way more refactoring than the current solution band-aid.

This is a rough estimate, but 3000 books would amount to maybe ~11-14MB. I'll consider it again if it becomes an issue.

joonaspaakko added a commit that referenced this issue May 16, 2021
I still got a bunch of small issues to resolve…
@joonaspaakko
Copy link
Owner Author

joonaspaakko commented May 31, 2021

Details about the fix:

I fixed it according to the original plan, but went for a hybrid solution where vertical scrolling updates URL param y (as in vertical offset) and that determines how many books are rendered on page load. Or if book details are open in URL params book, that overrides the scroll distance and loads as many books as are needed to get to the book.

In my test before the fix, I used an Iphone 8 and a library with around 1000 books. It was so slow that it was almost unusable. Now it's very smooth

Pros:

  • Faster load time of books when scrolling even on devices that didn't really feel sluggish before.

Cons:

  • You may still get a laggy experience if you load the page from a URL that ends up loading too many books at once for your device to handle

At first when I was building this lazy load system I made it so that if you loaded a page with book details open, It would load one book and nothing else, but with a button that says "Expand view (200)" parenthesis had the number of books in the collection... and when you click it. it would show everything in the collection. This I thought was an ok compromise, however I changed my mind when I realized that backwards navigation (back button in the browser) would always reset the view and throw you to the top. This was super irritating and so this current solution ended up being the lesser evil... I suppose.

joonaspaakko added a commit that referenced this issue Jul 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants