Add Lazy loading by default to CP Core

[discobot]

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 https://core.trac.wordpress.org/ticket/44427 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: GitHub · Where software is built

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

There’s now a plugin that claims to do this: LH Native Lazy Loading – WordPress plugin | WordPress.org I am going to give it a try.

~ posted by Tim Kaye

Hmm, that plugin causes conflicts. I found it much more effective to use the ‘wp_get_attachment_image_attributes’ filter with conditionals and a counter on the front page and archive/category templates.

~ 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

My tuppence worth: I wouldn’t be in favour of adding any “non-standard standard” to the core. Adding non-standard code that only Chrome can utilise could be perceived as an endorsement for Chrome.

~ posted by 1stepforward

I’d like any automatic addition of HTML attributes to wait until they are an official standard.

~ posted by zigpress

[viktor]

Lazy loading was added to WordPress. Should we consider backporting this feature?

[anon98749105]

Yes, it’s one thing I miss from WP… This gets my vote.

[timkaye]

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

[joyously]

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.

[MattyRob]

There is a PR for this on GitHub:

Add/lazy loading

[viktor]

This was introduced in v1.5.0. It will be included in the re-fork for v2.