Bring back load_delay ?

[Tenchi2xh]

Hey there, nice library, thanks for all the work 😄

I have a particular use case where I have a page full of images, but each image is generated server side. When the URL for an image is loaded, the server creates a docker container, does some pretty heavy stuff, and returns a computed image.

To prevent the server from crashing, I need some lazy loading to avoid loading the whole page at once, but also some protection against very fast scrolls that will trigger lots of image renders.

While searching for a way to prevent that in the issues of this project, I found that there used to be a load_delay option that only starts loading an image after it's been on the viewport for a certain amount of time, and that's exactly what I need (#235, #166)

The release notes say:

Removed the load_delay option since there's no more use for it

But in this case, that's not actually true, because using the feature that replaced load_delay, cancel_on_exit, will still trigger a bunch of render requests, promptly cancelling them, ignoring the responses because they are cancelled, all of that leading my server still exploding 💥

So I'd argue that load_delay and cancel_on_exit are only equivalent from a client's point of view, but totally different server side, so they are different features 😅

For now I am going to use an older version, but it doesn't feel nice to be behind on fixes and improvements.

[verlok]

Hey @Tenchi2xh,
thank you for reporting this.

I get your point and I'll think about reintroducing load_delay.

When I firstly introduced load_delay it was in fact to optimize for fast scrolling users, and it worked, but it also delayed the rendering of the images, which in turn results in a worse user experience, since having to wait say 200 ms to even start downloading images which usually would take 200 ms time to fully download is a huge waste of time.

The recently introduced cancel_on_exit option still optimizes for fast scrolls (in a different way and still making requests to the server, you're right) but without delaying the moment in which images start loading.

So when I introduced the cancel_on_exit option, I removed load_delay because the new one achieves the same result in a better way, ultimately optimizing the user experience.

Now if you ask me, you're probably taking the wrong approach to solve the problem. You're trying to protect your server by limiting the number of requests it receives, but what if your website audience increases and your server gets the double, or triple of visitors at a given time? You would get the same problem again. And increasing the load_delay wouldn't solve the problem, it would only make your user experience worse.

In my opinion, the correct approach to solve your problem would be to make your server scale, by either:

1. be able to detect and handle the canceled HTTP requests
2. adding a cache layer in front of it, like a CDN
3. make it automatically scale on a traffic spike

There are also commercial alternatives to generate images on the server side, like Cloudinary and Akamai Image and Video Manager, that probably solve the same problem you're trying to solve, but in a more flexible and scalable way.

Please let me know what you think.

[Tenchi2xh]

Now if you ask me, you're probably taking the wrong approach to solve the problem. You're trying to protect your server by limiting the number of requests it receives, but what if your website audience increases and your server gets the double, or triple of visitors at a given time? You would get the same problem again. And increasing the load_delay wouldn't solve the problem, it would only make your user experience worse.

Oh, it's for an internal app that will be used by at most 5 or 6 people in a small company. The server in question rendering images is Grafana while using the feature to render statistics panels, and that app isn't scalable. As for detecting the canceled requests or other solutions I would need to make my own fork and host it myself (we use a SAAS).

I would totally agree with your solutions if I was building a real user-facing product 🙂

And since it is only an internal app, all 6 of us really don't mind at all waiting 200ms to avoid crashing our statistics server haha

Thanks for the thoughtful answer!

[verlok]

You’re welcome.

In that case, I think you’re pretty good using version 15.2.0 of vanilla-lazyload.

Don’t feel bad being updated to an older version, it doesn’t have any bugs, it’s fast and it does exactly what you need.

The reason is that reintroducing load_delay would create more corner cases which will need to be managed writing more code, making the library heavier for a feature that almost nobody would use.

[Tenchi2xh]

True ! I will then close the issue

[verlok]

Hey @Tenchi2xh,
I’m glad this conversation was satisfying!

If you’re happy with my support, the documentation and the effort I’ve been putting on this project in the latest years, you might want to buy me a coffee to show your appreciation.

Open-source software is great for everyone, but it takes passion and time (and conversations like this) to grow and evolve.

Thank you for considering it.
Have a nice day!

[philipp-winterle]

Hey verlok,

I would love to reopen this issue with a real world example. In my company we are using highly generated pages with lots of picture tags which all include about 5 to 8 resolutions for different devices.

Then also we have a newsletter which is sent do above 1 million users. In this newsletter there are links to some of our sites. Most of them referring to one topic on that pages, navigated by a anchor.
You may have gotten the use case. Just build up a page with about 20 picture tags and double the text of the picture height below every picture. Then put in a anchor tag (#test) on the last headline above the last picture tag. When you jump in (without cache), the browser will immediately jump (or scroll blazing fast) to the known position. cancel_on_exit may work on most of the devices, but especially with iOS13+ devices we got the behavior that our anchor is in a totally different position after loading all the images scrolled over. Which is quite normal because we do not use any height and width adjustments to the img tag (responsiveness).

I was remembering an options to delay the loading and I want to try it, but as it seems you have removed it.
In my special case I would build a delay option in ms, which allows to me delay the loading of images when not scrolled by a human. (anchor tag "jump")
I would set it amount to 50ms? and would so achieve the same document height while being able to process all images in the target viewport.

Does this makes sense to you?

[verlok]

Hey @hummal
sorry for the delay in this reply.

You can try with LazyLoad 15.2.0, which have the load_delay option, and see if that solves your corner case.
You can find version 15.2.0 documentation here.

Anyway I do think that...

Then also we have a newsletter which is sent do above 1 million users. In this newsletter there are links to some of our sites. Most of them referring to one topic on that pages, navigated by a anchor.
You may have gotten the use case. Just build up a page with about 20 picture tags and double the text of the picture height below every picture. Then put in a anchor tag (#test) on the last headline above the last picture tag. When you jump in (without cache), the browser will immediately jump (or scroll blazing fast) to the known position. cancel_on_exit may work on most of the devices, but especially with iOS13+ devices we got the behavior that our anchor is in a totally different position after loading all the images scrolled over. Which is quite normal because we do not use any height and width adjustments to the img tag (responsiveness).

...given you are not able to preset images heights, due to responsiveness, it's a bad idea to make the links point to an anchor down below. Even if the blazing-fast-scroll-down works and the anchor position is maintained, when the users scroll up they would see the website moving down.

So if I was you I would rather consider removing the anchor, or putting what you're pointing to with the anchor in a specific landing page.

Let me know what you think.

[philipp-winterle]

Hey @verlok,

thanks for you reply.

load_delay has some positive impacts on the result but did not solve it entirely. This is due to reloading styles from elements not in visible areas. So I guess you can leave it as it is.

Iam sure that anchor urls are a big topic in enterprise environments. In my case it is not an option to remove an anchor from that pages because it is crucial to guide the customer to the information he is searching for. Also it is already a landing page.

But this doesn't seem to be a topic for your library. Thanks or hearing me.

[verlok]

Hey again @hummal

the right approach there is to occupy vertical space before the images are loaded by LazyLoad.

So when they get loaded, they don’t move the page up or down, avoiding to mess with your anchors.

Doing that will also optimize the CLS core web vital.

Up to you to find a way to deal with the fact that the height of your images might vary due to responsive images with the picture tag. 😅

If you’re happy with my support, the documentation and the effort I’ve been putting on this project in the latest years, I hope you might want to buy me a coffee to show your appreciation.

Open-source software is great for everyone, but it takes passion and time to grow and evolve.

Thank you for thinking about it.
Have a nice day!