News for hackers. Stuff that matters.
Re:The specification for native image lazy-loading is merged... by jameslk on Wednesday February 12, 2020 @11:09PM (#22315268)
The point of lazy loading images is generally to spare the browser from making a bunch of upfront requests to below the fold content, thereby making it so the page and content in the viewport is ready faster.

If images aren't ready by the time you scroll down, this is more an issue with the particular implementation of lazy loading, but the concept is sound.

Re:The specification for native image lazy-loading is merged... by greggman3 on Thursday February 13, 2020 @03:54AM (#22316297)
I always thought the point of lazy loading is to save the company serving the on bandwidth costs. AFAIK it's never been a good user experience scrolling down and then having to wait for images to load.
Re:The specification for native image lazy-loading is merged... by amalcon on Thursday February 13, 2020 @08:26AM (#22317516)
That's exactly what it's for. Modern browsers already optimize request order to grab above-the-fold stuff first. Below-the-fold images are loaded eagerly, but only after that.

Of course, they aren't perfect at this, because in general figuring out what's above or near the fold is equivalent to the halting problem (thanks, Javascript!). They do it well enough for the typical case, though.

Lazy loading is all about the hosting costs.

Re:The specification for native image lazy-loading is merged... by jameslk on Thursday February 13, 2020 @08:36AM (#22317587)
Given prolific use of CDNs and the abundance of cheap bandwidth, saving the transfer of some images isn't as much as a concern as it may have been once upon a non-cloud point in time.

However, if 40-50% of your visitors bounce because your page takes 5s to load[0][1] due to your longform photo essay hammering the user's 4G connection with a bunch of images they won't even see 5 minutes into scrolling down, this is a real concern. Lazy loading shines in these moments.

0. https://royal.pingdom.com/page-load-time-really-affect-bounc...

1. https://developers.google.com/web/fundamentals/performance/r...

Re:The specification for native image lazy-loading is merged... by shakna on Thursday February 13, 2020 @06:34AM (#22316904)
In any decent implementation, the lazy loaded images should be loaded before you scroll to them, unless you're jumping halfway down a page. They don't just load what's visible, but also the next section that it's expected you'll scroll to.
Re:The specification for native image lazy-loading is merged... by anoncake on Friday February 14, 2020 @06:51AM (#22325821)
A decent implementation would require precognition or at least telepathy. You cannot know when the user scrolls where. Web pages are random access.
Re:The specification for native image lazy-loading is merged... by prox on Thursday February 13, 2020 @07:16AM (#22317128)
Also depends on the skill of the maintainer. Some unskilled maintainers joyfully upload high res unoptimized images (esp if the cms also doesn’t have constrains in place)
Re:The specification for native image lazy-loading is merged... by stkdump on Thursday February 13, 2020 @02:36AM (#22316007)
Forgive my ingorance, but wouldn't that mean that the browser has to load images in the correct order? So instead of delaying the load until the image is in view, just prioritize loading based on how far up/down the page an image is? If yes, couldn't the browser implement it without any additions to html?
Re:The specification for native image lazy-loading is merged... by ioulian on Thursday February 13, 2020 @03:45AM (#22316262)
It's not that easy. It's not always that you scroll gradually to the bottom of the page. If you click the scrollbar to the bottom, then the middle images shouldn't load. The same if you use hash navigation to the bottom.

If you refresh the page at the bottom, it will stay at the bottom, so no need to load top images.

Re:The specification for native image lazy-loading is merged... by stkdump on Friday February 14, 2020 @07:28AM (#22325984)
Ok, but either way, isn't that logic that browsers could apply without changes to html?
Re:The specification for native image lazy-loading is merged... by abruzzi on Thursday February 13, 2020 @11:02AM (#22318749)
the problem usually looks more like this: I load a page and start reading. When I'm done reading the text/content in the viewport, I scroll down. On a lazily loaded page, now it needs to download the content in the new viewport position. On a non-lazily loaded page, the time I took to parse the initial content allowed the browser to complete loading the page. So effectively the lazily loaded page is taking the 10 seconds it takes to load the page, and rather than doing it while I'm occupied on other things, it holds on to most of that ten seconds, and spends that time when it interferes with what I'm doing, paying it out--2 second wait here, 2 second wait there.

Obviously this is an implementation detail and well done LL could keep loading everything until its done, but frequently it doesn't try until I scroll down. NonLL pages also aren't perfect, and if a page tries to load everything at once, each thing added slows everything else down. But for some reason I never experience that on non-LL pages (or maybe they're good LL pages and I don't notice.) It could be that browsers do some smart things (the obvious would be something like queueing requests for page content, only allowing 5 or so open requests, and loading images in the order they are referenced in the HTML so stuff at the bottom of the page is loaded last.)

Re:The specification for native image lazy-loading is merged... by lazyjones on Thursday February 13, 2020 @05:54AM (#22316747)
>The point of lazy loading images is generally to spare the browser from making a bunch of upfront requests to below the fold content, thereby making it so the page and content in the viewport is ready faster.

In practice, it has the opposite effect when the browser needs to figure out where on the page the image will end up at before attempting to load it.