Evidently a new loading attribute is working its way through WHATWG into the HTML standard! It supports lazy, eager, and auto. Sounds like it will allow basically the same thing as Jetpack's (and others') current JS-based lazy loading.
Background:
https://addyosmani.com/blog/lazy-loading/
https://github.com/scott-little/lazyload
Support right now (May 2019) is approximately zero - https://caniuse.com/#feat=loading-lazy-attr - but will obviously grow. Consider this a placeholder for discussion if and when Jetpack wants to start using it in addition to (and maybe eventually instead of) the current JS implementation.
Thanks for everything you all do!
If any other folks come to this issue, last week in Chrome 76 support for this attribute was introduced. There's a bug report for it in Firefox but no evidence yet that they're planning to work on it.
This issue has been marked as stale. This happened because:
No further action is needed. But it's worth checking if this ticket has clear reproduction steps and it is still reproducible. Feel free to close this issue if you think it's not valid anymore — if you do, please add a brief explanation.
According to caniuse, Firefox is adding this support in version 75. They've closed the bug report, as well. Edge has also added it with their move to Chromium.
Noting that this feature will be added to WordPress itself in version 5.5:
https://make.wordpress.org/core/2020/02/25/lazy-loading-update/
Jetpack will consequently be updated accordingly.
Noting that the feature just landed in Core, so we can start working with it:
https://core.trac.wordpress.org/changeset/47554
Introduces
wp_lazy_loading_enabled(),wp_filter_content_tags(),wp_img_tag_add_loading_attr(), andwp_img_tag_add_srcset_and_sizes_attr()functions.
Introduceswp_lazy_loading_enabled,wp_img_tag_add_loading_attr, andwp_img_tag_add_srcset_and_sizes_attrfilters.
Opening the conversation for how Jetpack should handle this moving forward.
We add a JS-based solution that works in more places than the loading attribute, but when we run our solution, we remove the src element of the img tag so isn't directly compatible.
Should we check user agent and only run our solution on Safari and IE (the two major browsers that lack support)? That's not great for caching.
Should we just drop our solution when running WP 5.5?
Or something more robust where we add our solution, then with JS re-add the src tag if on a browser supporting the spec to lean back into browser based support?
Personally, I lean toward the second since the relative number of users on an unsupported version will decrease quite a bit in the near future.
I would also suggesting dropping our solution for sites running WordPress 5.5+. Once a third of the web starts supporting the loading attribute, I assume major web browsers will look into it too. Maybe they're already working on this?
cc @josephscott, who may know more and should be able to weigh in on the impact this would have.
In terms of just the loading attribute, if WP core is doing it already, there isn't really a point to Jetpack doing it as well.
One of the challenges with the loading attribute in Chrome is that it is over eager, meaning it loads more images than in really should. Pure JS implementations have the ability to adjust how eager they want to be about loading images. So having that option in Jetpack would still be helpful. However, we'd need to make it clear to the site owner exactly what Jetpack would be doing in that case.
Jetpack could stop doing the loading attribute technique entirely and only do the JS version. That would at give a clearer line as to why they would pick one over the other.
Here is the related dev note with filters we can use:
https://make.wordpress.org/core/2020/07/14/lazy-loading-images-in-5-5/
To keep this issue clean, I'm going to close it to defer to Core's implementation of adding the loading attribute.
Most helpful comment
In terms of just the
loadingattribute, if WP core is doing it already, there isn't really a point to Jetpack doing it as well.One of the challenges with the
loadingattribute in Chrome is that it is over eager, meaning it loads more images than in really should. Pure JS implementations have the ability to adjust how eager they want to be about loading images. So having that option in Jetpack would still be helpful. However, we'd need to make it clear to the site owner exactly what Jetpack would be doing in that case.Jetpack could stop doing the
loadingattribute technique entirely and only do the JS version. That would at give a clearer line as to why they would pick one over the other.