17 comments

[ 3.1 ms ] story [ 15.5 ms ] thread
(comment deleted)
I really dig this approach. Pretty clever.
Rendering an anchor in the place of an image in case I don't have JavaScript enabled doesn't feel very good.

I'd much rather have image solutions that fail gracefully if the JS on my page is broken or the user just has it disabled.

It would be nice if they supported an anchor with a noscript tag inside containing the image
Why not? I think it is a fair replacement for a lot of image use-cases. If JS is turned off, users still have the ability to view the image and description, without the image hurting your total page weight.
Have a style sheet at the bottom of the page below some js. The js sets up lazy loading and changes all the image div id/classes so the style sheet does nothing. The style sheet sets the image divs backgrounds to your images otherwise. That should still work without js. Although it's a mess to work with...
How about lazily turn <a> into <img> without hurting performance ? It's useful if the network is slow.
Or maybe, and this might sound crazy, just USE THE FUCKING IMAGE TAG.

Seriously, websites where the images are broken without javascript are FUCKING ANNOYING.

There are image formats that support progressive rendering. Use those if you're that desperate, but STOP BREAKING THE FUCKING INTERNET FOR NO GOOD REASON.

Native lazy-loading[0] is coming in Chrome 75.

<img src="celebration.jpg" loading="lazy" alt="..." />

[0] https://addyosmani.com/blog/lazy-loading/

With some caveats, like "An implementation detail of loading in Chrome is that it fetches the first 2KB of images on page-load.".

That's the first 2KB of every image.

So on the server side I will have lots of errors/exceptions because only 2kb were loaded of each image?
I assume it does a range request. I was more pointing out that the client will still make a lot of requests. So maybe still not a good approach for long pages with tons of images below the fold.
Great⸮ As a regular underground public transportation commuter (without a data connection, except at very specific stations), I might soon have to scroll through an entire page of lazy-loaded images to ensure the page will be accessible for consumption during my trip!

But it’s a good thing, textual content will be easier to consume.

My webpage might need to load 1000 images eventually. It's kinda inefficient to try and load them all at the start, especially if the user is never going to scroll through all of them.

Also, progressive rendering solves an entirely different problem.

> My webpage might need to load 1000 images eventually. It's kinda inefficient to try and load them all at the start, especially if the user is never going to scroll through all of them.

That's a fair concern, but this library won't help with that.

I don't get why this is supposed to be particular accessible. <img> is perfectly fine, the alt attribute should describe the contents for users with screen readers and crawlers.