Fwiw the idea here is bandwidth-minimisation. I.e.: you only incur the image download cost if you choose to scroll. It's common practice on a lot of article/blog/content websites.
That said it's possible to implement this in a "graceful" way (where the mechanism only kicks in if JS is enabled & JS-less users just download all images at once), but this best practice is sadly rarely followed as it is admittedly somewhat more complex to implement.
> (where the mechanism only kicks in if JS is enabled & JS-less users just download all images at once)
This can fail and increase the bandwidth used if you only have a couple of images or have users on very fast connections.
I've seen it done by sending the image tag, and at the end of the document scanning the DOM for marked image tags and changing the URL specified to a low-quality copy (much smaller data size but looks a little like the image) or a small place-holder (perhaps even a data:url image) with the original getting put back when the image is visible (or about to be). The issue being that with a small number of images or a fast connected user the main large files start loading before the HREF attribute is updated and the transfer is not aborted when it is changed so the user always loads both the main and place-holder image. You can improve this plan a little by emitting the JS to alter each relevant image tag immediately after it, but that can cause multiple-reflow/-repaint issues.
> admittedly somewhat more complex to implement
Aye, and sometimes it is simply worth losing a few viewers to save a bit of faf. Though care should be taken with regard to collateral damage: as with all methods that exclude people who have chosen to have JS turned off this can easily exclude those with accessibility issues which is far less acceptable.
> where the mechanism only kicks in if JS is enabled
Of course there is now a commonly available method of doing lazy loading built-in so that is the best way to go, for those few with an ancient or otherwise alternative browser that doesn't support the feature yet the images just load immediately: https://caniuse.com/loading-lazy-attr. You can augment this is JS for those that have it turned on if you wish, perhaps on long documents implementing early-lazy loading (start the load when the user scrolls to within on display-window of content rather than when first visible) by removing the lazy attribute at an appropriate time detected using the same methods as you do for entirely manual lazy loading support, or using the replace-with-low-res-copy method in place of attribute based lazy-loading when JS is available.
That's not why these types of sites do it. They do it because they only make money if you run the arbitrary javascript from their advertisers. If you won't run their code they won't show you what you're there to see. It's a computational paywall.
Fwiw the idea here is bandwidth-minimisation. I.e.: you only incur the image download cost if you choose to scroll. It's common practice on a lot of article/blog/content websites.
That said it's possible to implement this in a "graceful" way (where the mechanism only kicks in if JS is enabled & JS-less users just download all images at once), but this best practice is sadly rarely followed as it is admittedly somewhat more complex to implement.