Lazy loading is a little too lazy - Load new content a little earlier and not just in the last row #383

Closed
opened 2026-02-19 23:07:41 -05:00 by deekerman · 13 comments
Owner

Originally created by @RAYs3T on GitHub (Aug 13, 2020).

Originally assigned to: @lastzero on GitHub.

When you scroll trough the pictures, new content is only loaded once you reach the last row.
This leads to empty fields while scrolling.

The next page should already load once you approach the last two or three rows.

Originally created by @RAYs3T on GitHub (Aug 13, 2020). Originally assigned to: @lastzero on GitHub. When you scroll trough the pictures, new content is only loaded once you reach the last row. This leads to empty fields while scrolling. The next page should already load once you approach the last two or three rows.
deekerman 2026-02-19 23:07:41 -05:00
  • closed this issue
  • added the
    idea
    label
Author
Owner

@lastzero commented on GitHub (Aug 13, 2020):

Might also point to a performance issue, new results typically load very fast. Those gaps are the result of stacked results as the database counts files while we show photos.

@lastzero commented on GitHub (Aug 13, 2020): Might also point to a performance issue, new results typically load very fast. Those gaps are the result of stacked results as the database counts files while we show photos.
Author
Owner

@RAYs3T commented on GitHub (Aug 13, 2020):

They are fast, no question. But it is still anyoing if this interrupts your "smooth scrolling" (it comes to an hard end for 1-2 seconds)

@RAYs3T commented on GitHub (Aug 13, 2020): They are fast, no question. But it is still anyoing if this interrupts your "smooth scrolling" (it comes to an hard end for 1-2 seconds)
Author
Owner

@lastzero commented on GitHub (Aug 13, 2020):

Alright, thanks for your feedback! Going to optimize this further after our release.

In fact, the next page might already be in memory since we perform preloading for the lightbox / photo viewer. But there are also a million things that can go wrong. We better don't mess with it shortly before a stable release.

@lastzero commented on GitHub (Aug 13, 2020): Alright, thanks for your feedback! Going to optimize this further after our release. In fact, the next page might already be in memory since we perform preloading for the lightbox / photo viewer. But there are also a million things that can go wrong. We better don't mess with it shortly before a stable release.
Author
Owner

@danielo515 commented on GitHub (Nov 6, 2020):

I was about to open a similar question, but I think it is worth discussing it first here since this is about lazy loading.
IMO lazy loading should happen earlier and load less photos. In my laptop photoprism feels slow, and I think that is because it loads too many photos and then has to render too many of them.
Here is a comparision, when I reach the end of the row, this is the count of requests:

image

121 requests per page, and, it feels to much. If you were loading way less (let's say, 20) but you fetch more as the page scrolls about the 50%, the feeling would be much more smoother.
Even if some images show up without being loaded, a nice fade in animation will give you the impression that it is loading faster.

For reference, here is the count of network request when I scroll half page on pig.js:

image

And when I scroll several times, and relatively fast:

image

In the first case, when I browse slowly I get less network load, and when I browse faster I get more network load, but in any case I get as many request in flight as with prism

Another cool feature of pig.js is that it allows me to scroll the entire content. For example, I can just pick the scrollbar and move it to the bottom. If an image with a network request that is in-flight scrolls out of the view, then the request is cancelled.

@danielo515 commented on GitHub (Nov 6, 2020): I was about to open a similar question, but I think it is worth discussing it first here since this is about lazy loading. IMO lazy loading should happen earlier and load less photos. In my laptop photoprism feels slow, and I think that is because it loads too many photos and then has to render too many of them. Here is a comparision, when I reach the end of the row, this is the count of requests: ![image](https://user-images.githubusercontent.com/2270425/98405041-e3c72200-206b-11eb-97ea-6f556d70d5c5.png) 121 requests per page, and, it feels to much. If you were loading way less (let's say, 20) but you fetch more as the page scrolls about the 50%, the feeling would be much more smoother. Even if some images show up without being loaded, a nice fade in animation will give you the impression that it is loading faster. For reference, here is the count of network request when I scroll half page on pig.js: ![image](https://user-images.githubusercontent.com/2270425/98405245-3a346080-206c-11eb-8681-85a4c4883ace.png) And when I scroll several times, and relatively fast: ![image](https://user-images.githubusercontent.com/2270425/98405305-546e3e80-206c-11eb-9867-04db47c3f0e4.png) In the first case, when I browse slowly I get less network load, and when I browse faster I get more network load, but in any case I get as many request in flight as with prism Another cool feature of pig.js is that it allows me to scroll the entire content. For example, I can just pick the scrollbar and move it to the bottom. If an image with a network request that is in-flight scrolls out of the view, then the request is cancelled.
Author
Owner

@lastzero commented on GitHub (Nov 8, 2020):

@danielo515 Frontend rendering should be optimized independently from how the API works, see #500

Since a new database query is performed every time you request search results and there might be quite some latency between client and server, it's often not helpful to load data in tiny batches.

@lastzero commented on GitHub (Nov 8, 2020): @danielo515 Frontend rendering should be optimized independently from how the API works, see #500 Since a new database query is performed every time you request search results and there might be quite some latency between client and server, it's often not helpful to load data in tiny batches.
Author
Owner

@benjaminknauer commented on GitHub (Jan 19, 2021):

Please consider using content-visibility: auto to increase performance when many images are displayed:

https://web.dev/content-visibility/

@benjaminknauer commented on GitHub (Jan 19, 2021): Please consider using `content-visibility: auto` to increase performance when many images are displayed: https://web.dev/content-visibility/
Author
Owner

@lastzero commented on GitHub (Jan 19, 2021):

Thanks, going to give it a try 👍

@lastzero commented on GitHub (Jan 19, 2021): Thanks, going to give it a try 👍
Author
Owner

@StephenBrown2 commented on GitHub (Jan 19, 2021):

No support in Firefox: https://developer.mozilla.org/en-US/docs/Web/CSS/content-visibility

@StephenBrown2 commented on GitHub (Jan 19, 2021): No support in Firefox: https://developer.mozilla.org/en-US/docs/Web/CSS/content-visibility
Author
Owner

@benjaminknauer commented on GitHub (Jan 20, 2021):

No support in Firefox: https://developer.mozilla.org/en-US/docs/Web/CSS/content-visibility

Right, but can be implemented with almost no effort and a possibly strong performance improvement for Chrome users.

Our company sees large benifits in performance via web vitals.

https://youtu.be/FFA-v-CIxJQ

@benjaminknauer commented on GitHub (Jan 20, 2021): > No support in Firefox: https://developer.mozilla.org/en-US/docs/Web/CSS/content-visibility Right, but can be implemented with almost no effort and a possibly strong performance improvement for Chrome users. Our company sees large benifits in performance via web vitals. https://youtu.be/FFA-v-CIxJQ
Author
Owner

@voronond commented on GitHub (Feb 20, 2022):

Are there any updates regarding this? I have like 40 000 photos saved and whenever I scroll down the page I usually need to wait 3 seconds, before new photos get loaded up.

Thank you.

PS: I absolutely love your application! That huge number of features it provides is amazing.

@voronond commented on GitHub (Feb 20, 2022): Are there any updates regarding this? I have like 40 000 photos saved and whenever I scroll down the page I usually need to wait 3 seconds, before new photos get loaded up. Thank you. PS: I absolutely love your application! That huge number of features it provides is amazing.
Author
Owner

@lastzero commented on GitHub (Feb 20, 2022):

Note that the query performance may depend significantly on the selected sort order. Also, there may have been a "bug" that prevented thumbnails from being cached:

Have you already read the Performance Tips section of our docs?

https://docs.photoprism.app/getting-started/troubleshooting/performance/

@lastzero commented on GitHub (Feb 20, 2022): Note that the query performance may depend significantly on the selected sort order. Also, there may have been a "bug" that prevented thumbnails from being cached: - https://github.com/photoprism/photoprism/issues/822#issuecomment-1046276315 Have you already read the Performance Tips section of our docs? https://docs.photoprism.app/getting-started/troubleshooting/performance/
Author
Owner

@RAYs3T commented on GitHub (Mar 2, 2022):

Having seen this now on multiple installations with different hardware (performance-vise), I think it would be great if an option is added for the user to customize the amount of prefretched media. It's just anoying if you try to scroll fast and it stops to load the row. There is only so much you can optimize in the terms of storage. If the fetch-new request is just fired too late you will still see the higup in the UI.

@lastzero A (default not set ) environment variable wich can be set in docker-compose would be enough. I see your approch with "keep it simple" and mostly agree, but this starts to get annoying if your don't organize your photos in albums a lot and have to quickly scroll trough them to search a specific one.

@RAYs3T commented on GitHub (Mar 2, 2022): Having seen this now on multiple installations with different hardware (performance-vise), I think it would be great if an option is added for the user to customize the amount of prefretched media. It's just anoying if you try to scroll fast and it stops to load the row. There is only so much you can optimize in the terms of storage. If the fetch-new request is just fired too late you will still see the higup in the UI. @lastzero A (default not set ) environment variable wich can be set in docker-compose would be enough. I see your approch with "keep it simple" and mostly agree, but this starts to get annoying if your don't organize your photos in albums a lot and have to quickly scroll trough them to search a specific one.
Author
Owner

@lastzero commented on GitHub (Mar 2, 2022):

I get it can be annoying, depending on the use case. Best we can offer short term are the Performance Tips in the docs. We just put our last bit of energy in the upcoming release which once again includes lots of major improvements, see Release Notes.

Please spread the word so we can eventually generate enough income to build a larger team, deliver faster, and work on more issues at the same time 💐

I promise scroll performance will be epic once we have a second to work on it.

@lastzero commented on GitHub (Mar 2, 2022): I get it can be annoying, depending on the use case. Best we can offer short term are the Performance Tips in the docs. We just put our last bit of energy in the upcoming release which once again includes lots of major improvements, see Release Notes. Please spread the word so we can eventually generate enough income to build a larger team, deliver faster, and work on more issues at the same time 💐 I promise scroll performance will be epic once we have a second to work on it.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/photoprism#383
No description provided.