Hacker News Reader

Comment by weinzierl | Hacker News Reader

Very first tip:

"Performance tip. You can use the loading=lazy attribute to defer the loading of the image until the user scrolls to them."

Can someone explain to me when this is useful?

As a content consumer I'm frequently annoyed, when I have to wait for images to load while scrolling.

As a content creator I understand the idea that I might potentially save the consumer some bandwidth, given they might - against all odds and for whatever reason - decide not to scroll down. Kidding aside I think that as a creator I should optimize for the readers that are thoroughly interested in my whole content and therefore I should preload and not lazy load.

View on HN

> As a content consumer I'm frequently annoyed, when I have to wait for images to load while scrolling.

That's the experience most javascript solutions gave you. This browser native solution will load images _before_ they're visible in the viewport so you do not get the fading-in flashes you often see. Combine it with setting the width and height on an element and your page also won't shift around as you scroll.

This will actually optimize for the reader as it will improve the time it takes before they can interact with your page. I also think you'd be very disappointed if you see the percentages of people that end up scrolling on any given page.

I've been using this in a script I wrote for myself which is basically a huge image gallery. This gallery may consist of thousands of images on a single page. When the browser always had to load all of those thumbnails, it consumed a lot of bandwidth and was very slow. In fact, the user experience was strictly worse because images are normally loaded in the order they appear on the website, so it took several seconds until the thumbnails at the end of the page were available. Now the browser just loads those thumbnails that I can see (or am about to see), and they are there pretty much instantly even if I scroll to the end of my gallery.

When I read that tip I was thinking whether I should use it on https://www.2uo.de/russland-2013/

It's a longish travel report, lots of photos, interspersed with comments. I think it might be nice not to have all of them loaded in the beginning. Especially since random visitors probably won't read it till the end.

Ideal in this case might be to load images that are within one or two screenfuls of the current position, then someone scrolling down actually ingesting the content might not be bothered by the delay as they probably won't see it. That would require JS though, and you need to deal with page resizes as well as scroll events. Also make sure you include width & height settings for the image tag or you scroll position reference will be off when considering images further down the page. Maybe load a low-res placeholder for the other images in case the user drops offline as they scroll, either an "image not loaded" marker just so they know something _should_ be there or a very compressed version of the actual photo.

It's more about saving bandwidth on the server side, plus it allows for tracking without using JS.

Exactly this. It's a problem already solved by pagination - but I guess that's not cool and doesn't allow for such granular tracking.

On the client side too. I use it to avoid loading below-the-fold images until it's necessary. For example, I don't load the thumbnails of related articles.

It makes a non-negligible impact on bandwidth usage and page load time.

To mitigate the tracking problem, Firefox only defers loading of images when JS is enabled: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/im...

Chrome seemed to behave this way as well when I tested it a while ago. It's covered in the spec: https://html.spec.whatwg.org/multipage/urls-and-fetching.htm...

This was my thought exactly. It's infuriating and unnecessary.

Reply on news.ycombinator.com