How does this even work if your not overriding src?

[garygreen]

Pretty much all lazy loaders need to use src2 or override it in some way due to the browser automatically fetching images with a src value - so I'm a bit baffled how does this library work exactly?

Does this library just hope that it can kick in quick enough to alter the attributes on dom load? (sounds rather fragile and unreliable if so...)

[mfranzke]

Thanks for your question. One of my most beloved sentences is „Technology is magic.“

But this doesn‘t relate to this piece of art.

You‘re perfectly right that in general the browser engine (even especially a specific preloader) does retrieve all sources within the document to load them asap. But that isn‘t the case for element outside of the DOM, like that stuff in a that it only treats as textual content - until you retrieve it and inject it with the modifications you were talking about for any browsers not supporting the loading-attribute so far.

The downside on overwriting the src-attribute is especially that it isn‘t valid and accessible HTML code anymore in the first place and doesn‘t gracefully degrade because of the JavaScript dependency, that you actually are able to prevent by using this technique.

[garygreen]

Thanks for the explanatation. I wonder if there is a way of using service workers to intercept requests to images and stop them from being downloaded unless they are in the viewport - tricky part would be somehow sending this meta data onto the service worker so it knows whether to allow loading or blocking of the image. Benefit of this approach would be a graceful/progressive enhancement, it won't break any browsers that don't support service workers and you won't need to update any of your image srcs / srcset stuff - the browser just requests for stuff and it's either accepted or blocked.

Maybe an idea to explore. Just thinking out loud 😃

[mfranzke]

Thanks for the explanatation. I wonder if there is a way of using service workers to intercept requests to images and stop them from being downloaded unless they are in the viewport - tricky part would be somehow sending this meta data onto the service worker so it knows whether to allow loading or blocking of the image. Benefit of this approach would be a graceful/progressive enhancement, it won't break any browsers that don't support service workers and you won't need to update any of your image srcs / srcset stuff - the browser just requests for stuff and it's either accepted or blocked.

Maybe an idea to explore. Just thinking out loud 😃

I‘m loving your idea and it‘s actually a nice approach worth looking into. Especially as there‘s no other way I could think of to intercept the network traffic - or in other words this might be an even nicer one which even also further follows the principals of progressive enhancement.

[mfranzke]

@garygreen thanks again for bringing up your idea with ServiceWorkers - it sadly took a lot of time due to several reasons to come up with a PoC and an evaluation of this topic.

I've identified the following aspects:

Pro

• The img or iframe elements wouldn't need to get wrapped by a noscript HTML tag any more, but still (as you've even also stated) we would need to identify the assets that are supposed to get lazy loaded.
  As Client hints within the HTTP headers aren't an option here, I've mainly identified that the best would probably be query parameters added to the URL (I even also thought about implementing those via the anchor, but this might have unexpected side effects regarding caching). Additionally we would need to retrieve the width and height (same values like the equally named HTML attributes) of the image for the SVG placeholder, which could as well get transferred via query parameters.

Con

• It doesn't work on non-HTTPS-websites - probably a minor, issue as HTTPS should be(come) the new normal hopefully.
• It doesn't work for assets referenced cross-domain, like images or an iframe URL from another service, like e.g. Vimeo, or some (central) CDN.
• It doesn't work at the first page impression, but only the ones afterwards, as the service worker needs to get initiated first.
• Obviously this polyfill wouldn't work on browsers that don't support ServiceWorker, which is mainly Microsoft Internet Explorer versions below 17; even though that there's a graceful degradation, as you've written as well already.

Still these might be tradeoffs that someone might be accepting due to the simplification regarding the HTML code changes.

Conclusion

I've uploaded this very simple PoC to this URL - it doesn't include any lazy functionality so far, but differentiating in between loading-lazy and non-loading-lazy could be done with removing the query parameters:
https://goofy-bell-6b1148.netlify.app/

I'm still motivated to even also offer this other solution as a new polyfill though.

[mfranzke]

@garygreen I've made it to a very first beta version of that approach – I'll update the README to meet the relevant installation and setup and will let you know as soon as this goes live. Thanks a lot again for the great idea with the service workers !!!