Skip to content
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

Lazy loading: use new HTML loading attribute #12512

Closed
snarfed opened this issue May 30, 2019 · 10 comments
Closed

Lazy loading: use new HTML loading attribute #12512

snarfed opened this issue May 30, 2019 · 10 comments
Labels
[Feature] Lazy Images [Focus] Performance [Pri] Normal [Type] Enhancement Changes to an existing feature — removing, adding, or changing parts of it
Milestone

Comments

@snarfed
Copy link
Contributor

snarfed commented May 30, 2019

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!

@jeherve jeherve added [Feature] Lazy Images [Pri] Normal [Type] Enhancement Changes to an existing feature — removing, adding, or changing parts of it labels May 30, 2019
@jonathanstegall
Copy link

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.

@stale
Copy link

stale bot commented Feb 9, 2020

This issue has been marked as stale. This happened because:

  • It has been inactive in the past 6 months.
  • It hasn’t been labeled `[Pri] Blocker`, `[Pri] High`.

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.

@stale stale bot added the [Status] Stale label Feb 9, 2020
@jonathanstegall
Copy link

jonathanstegall commented Mar 12, 2020

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.

@stale stale bot removed the [Status] Stale label Mar 12, 2020
@jeherve
Copy link
Member

jeherve commented Mar 12, 2020

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.

@jeherve
Copy link
Member

jeherve commented Apr 8, 2020

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(), and wp_img_tag_add_srcset_and_sizes_attr() functions.
Introduces wp_lazy_loading_enabled, wp_img_tag_add_loading_attr, and wp_img_tag_add_srcset_and_sizes_attr filters.

@kraftbj
Copy link
Contributor

kraftbj commented Apr 8, 2020

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.

@jeherve
Copy link
Member

jeherve commented Apr 9, 2020

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.

@jeherve jeherve changed the title Lazy loading: use new HTML loading attribute (eventually) Lazy loading: use new HTML loading attribute Apr 9, 2020
@josephscott
Copy link
Contributor

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.

@jeherve jeherve modified the milestones: 8.7, 8.8 Jun 30, 2020
@jeherve
Copy link
Member

jeherve commented Jul 15, 2020

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/

@kraftbj
Copy link
Contributor

kraftbj commented Jul 27, 2020

To keep this issue clean, I'm going to close it to defer to Core's implementation of adding the loading attribute.

@kraftbj kraftbj closed this as completed Jul 27, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Lazy Images [Focus] Performance [Pri] Normal [Type] Enhancement Changes to an existing feature — removing, adding, or changing parts of it
Projects
None yet
Development

No branches or pull requests

5 participants