-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How does this even work if your not overriding src? #88
Comments
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. |
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. |
@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
Con
Still these might be tradeoffs that someone might be accepting due to the simplification regarding the HTML code changes. ConclusionI'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: I'm still motivated to even also offer this other solution as a new polyfill though. |
@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 !!! |
Pretty much all lazy loaders need to use
src2
or override it in some way due to the browser automatically fetching images with asrc
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...)
The text was updated successfully, but these errors were encountered: