Borrowing the description;
In Chrome 76, you can use the loading attribute to completely defer the loading of offscreen images and iframes that can be reached by scrolling:
Here are the supported values for the loading attribute:
> auto: Default lazy-loading behavior of the browser, which is the same as not including the attribute.
> lazy: Defer loading of the resource until it reaches a calculated distance from the viewport.
> eager: Load the resource immediately, regardless of where it's located on the page.
Morten in #44427 (Introduce lazy-loading API for media and other elements) ā WordPress Trac makes a good case for this. Can we work on this since it does not make any breaking changes? It is an enhancement that I see since I come from a location where we have bad bandwidth and network.
See lazy loading in effect here: https://web.dev/native-lazy-loading/lazyload.webm
Read-only archive : Issues Ā· ClassicPress/ClassicPress Ā· GitHub
Author : Laurence Bahiirwa
Vote count : 18
Status : Completed (v1.5.0)
Comments
To be fair, I donāt think Morten did make a good case for this initially. Only when JakePT stepped in to point out the typical problems with lazy loading did he then point out that Googleās spec for lazy loading still means that images get loaded before they enter the viewport.
So long as that is how ClassicPress would implement this, then Iād be in favor. If we did it the way itās typically done at the moment, however, with images being loaded only when they actually come into view, then Iād be strongly against.
~ posted by Tim Kaye
@Tim Kaye - weāre not actually implementing anything, thatās why I like this idea - itās just using the native browser support if it exists. Still needs testing of course, but the possibility of this breaking anything is exactly zero if the browsers work as they should.
~ posted by invisnet
@invisnet : Good. Thanks!
~ posted by Tim Kaye
I donāt think that we should add this support because is not a standard yet and is supported only by Chrome Can I use... Support tables for HTML5, CSS3, etc
So this will require also to include a polyfill for all the browser that doesnāt support it, this mean a js file to include in all the pages.
~ posted by Daniele Scasciafratte
@Daniele Scasciafratte: Why would it need a polyfill? Why couldnāt it be implemented just so that those using Chrome get to take advantage? It doesnāt make any difference to those using other browsers.
My main concerns, now that Iāve tried this out using a filter, are that:
(a) It actually doesnāt do much for most sites. The main use case for this is mobile, but there isnāt a mobile browser that supports it; and
(b) There is no clarity yet on whether this is going to become standardized. If not, we will be setting an awkward precedent for ourselves. And if some other standard is then set, weāll have to undo this and implement the new standard.
~ posted by Tim Kaye
Google has just released a plugin to do this: Native Lazyload ā WordPress plugin | WordPress.org
āIf the loading attribute is not supported by the browser, the plugin falls back to a JavaScript solution based on IntersectionObserver. For the case that JavaScript is disabled, but the loading attribute is supported by the browser, a noscript variant of the respective element will be added that also includes the loading attribute without any further changes.ā
WP-Tavern reports that itās been causing a significant improvement in load time.
~ posted by NyssaTheHobbit
Update: I just installed the plugin on both my sites and disabled BJ-Lazy Load. So far, itās working fine. I havenāt seen a change in load speed on online testers, but when I test it on my browsers, it appears to be working better than before.
~ posted by NyssaTheHobbit
Now that they fixed a conflict with Autoptimize, I am seeing a difference in load times, especially Chrome vs. Firefox. I finally see Aās and Bās in my First Byte score.
~ posted by NyssaTheHobbit
viktor
September 1, 2021, 7:38am
2
Lazy loading was added to WordPress. Should we consider backporting this feature?
1 Like
Yes, itās one thing I miss from WPā¦ This gets my vote.
timkaye
September 1, 2021, 4:48pm
4
Itās now more-or-less a web standard: "loading" | Can I use... Support tables for HTML5, CSS3, etc
But thereās quite a few changesets involved. Just recording them here for future reference:
47554
48170
48237
48272
48648
48649
2 Likes
From what I could tell in the support forums, the original lazy load worked, but the attribute was added to all images. They fixed it so it wasnāt added to the header image.
In a later release, they added it to iframes. This caused problems, and Iām not sure that is all fixed.
I would put it only on images.
1 Like
There is a PR for this on GitHub:
ClassicPress:develop
ā mattyrob:add/lazy-loading
opened 12:42PM - 30 Dec 21 UTC
## Description
This is a collection of backports to add image lazy loading fromā¦ upstream.
Included are:
https://core.trac.wordpress.org/changeset/47554
https://core.trac.wordpress.org/changeset/48170
https://core.trac.wordpress.org/changeset/48237
https://core.trac.wordpress.org/changeset/48239 (in addition to existing Issue)
https://core.trac.wordpress.org/changeset/48272
https://core.trac.wordpress.org/changeset/48648
https://core.trac.wordpress.org/changeset/48649
48239 was included as it introduced additional checks for lazy loading and the commit was not captured in upstream tickets. It was noted in the backport of 48272 where a unit test broke, this test was contingent on the changes made in 48239
## Motivation and context
Closes #538 and will enable lazy loading of images including filter for sites to opt out if needed
For further consideration are the backports for iframe lazy loading and the performance improvements in change 52065
## How has this been tested?
This PR includes unit tests for new functionality.
## Screenshots
N/A
## Types of changes
- New feature
1 Like
viktor
January 14, 2023, 5:31am
8
This was introduced in v1.5.0. It will be included in the re-fork for v2.