[Enhancement] Display of images within lightbox (preload and use of low-res) about lychee-front HOT 13 CLOSED

I'd like to propose two enhancements to improve the UX:
(1) Use low-res to start with

• Use the already cached low resolution version of the album view to start with
• Once the actual image for the lightbox is loaded, change to this version

No problem with that.

(2) Pre-load of images

• Preload the neighboring (i.e. predecessor and successor) images of the album when a new image is display in the lightbox

This is actually already implemented (but only one picture each side: previous and next).

from lychee-front.

(1) Use low-res to start with

• Use the already cached low resolution version of the album view to start with
• Once the actual image for the lightbox is loaded, change to this version
  No problem with that.

I agree it's a good suggestion. Do you have an idea how to implement it though? Things get complicated with @2x images: we don't actually know which one is in the cache (for small) or which one the browser is planning to load (for medium). Is there a way to query the browser cache content from JS? A quick web search didn't return any obvious answers...

(2) Pre-load of images
This is actually already implemented (but only one picture each side: previous and next).

Actually, I believe we only do it for the next (photo.preloadNext). We could of course expand it to cover both previous and next but I'm not sure if that would make the matters better or worse (i.e., parallel loading of two images will only make things slower, although in the case of somebody browsing from one image to the next, the previous one is likely to be cached already).

from lychee-front.

(1) Use low-res to start with

• Use the already cached low resolution version of the album view to start with
• Once the actual image for the lightbox is loaded, change to this version
  No problem with that.

I agree it's a good suggestion. Do you have an idea how to implement it though? Things get complicated with @2x images: we don't actually know which one is in the cache (for small) or which one the browser is planning to load (for medium). Is there a way to query the browser cache content from JS? A quick web search didn't return any obvious answers...

You're right, the implementation seems to be much more complicated than I thought in the first place. What about the following idea (don't know it if works in the end):
You can access the current source of an image using currentSrc (https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement). We look at the thumbnail in the album view and have 3 cases:

1. currentSrc = small: -> use the small version
2. currentSrc = @2x -> use the @2x version
3. currentSrc = placeholder -> (for discussion) use the small version
   What do you think?

(2) Pre-load of images
This is actually already implemented (but only one picture each side: previous and next).

Actually, I believe we only do it for the next (photo.preloadNext). We could of course expand it to cover both previous and next but I'm not sure if that would make the matters better or worse (i.e., parallel loading of two images will only make things slower, although in the case of somebody browsing from one image to the next, the previous one is likely to be cached already).

1. Does not work consistently
   Did some more testing - it does not seem to work consistently.
   Safari (on Mac): Next image is not preloaded. Looking at the traffic, it seems like Safari is loading the thumb version of the next image, but not the medium one. Without looking at the traffic, it seems the iPhone behaves on the same way.
   Firefox: Is working
2. Loading previous image
   This should only make the first image view slower. When iterating forwards, the previous image is already cached. When iterating backwards, preloading of previous image is helpful (next image is already cached)

from lychee-front.

What about the following idea (don't know it if works in the end):
You can access the current source of an image using currentSrc (https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement).

Yes, we actually use currentSrc already, in the preload code. I was thinking about it and came up with pretty much the same idea as you have.

We look at the thumbnail in the album view and have 3 cases:

1. currentSrc = small: -> use the small version
2. currentSrc = @2x -> use the @2x version
3. currentSrc = placeholder -> (for discussion) use the small version

What do you think?

Yeah, exactly. When switching from the album view to the photo view (by clicking on a thumbnail) the thumbnails aren't actually removed from the screen; they just get covered up. So it should be quite simple to look up the thumbnail and initially display whatever it is displaying (since that's obviously cached). Regarding the 3rd scenario above, I would simply do nothing (i.e., fall back to what we currently do) as that's not a common case.

1. Does not work consistently
   Did some more testing - it does not seem to work consistently.
   Safari (on Mac): Next image is not preloaded. Looking at the traffic, it seems like Safari is loading the thumb version of the next image, but not the medium one. Without looking at the traffic, it seems the iPhone behaves on the same way.
   Firefox: Is working

The thumb loading you're seeing is due to the background images behind the "prev" and "next" arrows of the currently displayed photo.

We are using standard HTML5 link prefetching. Indeed, according to https://caniuse.com/#feat=link-rel-prefetch you are correct that Safari doesn't support it. Shame. Given that pretty much every other browser supports it, I'm not exactly motivated to do anything about it. But if somebody submitted a clean PR we would probably consider it (preloading can be achieved in JS without HTML5 by creating an Image object and setting its source to the desired URL)...

2. Loading previous image
   This should only make the first image view slower. When iterating forwards, the previous image is already cached. When iterating backwards, preloading of previous image is helpful (next image is already cached)

Yes, exactly.

from lychee-front.

Given that pretty much every other browser supports it, I'm not exactly motivated to do anything about it.

👍

from lychee-front.

This discussion reminded me of something that bothered me about Lychee from the beginning: the fact that the last picture wraps around to first when you click on the next arrow. I never liked that so I now fixed it (well, I made it configurable) and in the process I also started working on your list. 😃

@tmp-hallenser, can you test the branch nextprev-improvements of Lychee-front and see if prefetching now works on Safari?

from lychee-front.

@tmp-hallenser I completed the implementation of this request in #130. It would be great if you could test it and provide feedback, especially with respect to the prefetching on Safari, which is currently untested.

from lychee-front.

Gave it a brief test - Safari now preloads the medium size image -> that's good. Many thanks!

I did some further testing regarding page speed and realized, that calling photo:get is now not the most time consuming call. In my case, the network protocol shows roughly 1000ms waiting before the transfer starts. (this is of course not related to the network speed but rather to the large library combined with low power of server). Hence another idea to improve the speed:

Can we also preload the call of photo:get?

There is the function preload which might be useful: https://developer.mozilla.org/en-US/docs/Web/HTML/Preloading_content

Unfortunately, the feature is disabled for Firefox by default.
https://caniuse.com/#search=preload

from lychee-front.

I have what I think is a fairly low-end server (a cloud instance with 512 MB RAM) that's over 1000km from me and Photo::get takes under 200ms on average, which I find quite acceptable.

DevTools in Chrome include a snazzy "Server Timing" breakdown under Network (I had no idea such info is even sent...) -- can you see if there's anything interesting in there that would shed some light into why it's much slower for you?

from lychee-front.

Here, same, my server is 1000km away and I have more than 6000 pictures on it. I still get responses over Photo::get within 100ms and my Laravel instance is runing inside a Virtualbox VM on my server.

from lychee-front.

My server (Docker on a raspberry) is in the same wifi and I've got approx. 30k photos.

The Server Timing is not shown for my installation and I found quite little resources on how to get it working. My timings for photo:get are:

Queueing: 1.34 ms
Stalled: 0.41 ms
Request sent: 0.22 ms
Waiting (TTFB): 1.19 s (<- that's the issue)
Content download: 1.52 ms

I've logged into the mysql server. A "SELECT * from photos WHERE ID=(some ID)" returns the result in 2ms -> that's also not the bottle neck.

I'll do some more testing if I find some more free time.

from lychee-front.

Did some further testing and the issue must be somewhere in my config. When using the provided Dockerfile based on Debian, I'm down to 180ms waiting compared to >1s (ngninx on an alpine base image)

from lychee-front.

I'm closing this issue since the originally requested functionality has been implemented.

from lychee-front.