ClassicPress PetitionsClassicPress Petitions
This is a read-only archive. Post or comment on the live version of this page on our forums.

Add Lazy loading by default to CP Core.

August 9, 2019 · 15:18 · Laurence Bahiirwa

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:

<img src="image.png" loading="lazy" alt="…" width="200" height="200">
<iframe src="" loading="lazy"></iframe>

Here are the supported values for the loading attribute:

&gt; auto: Default lazy-loading behavior of the browser, which is the same as not including the attribute.
&gt; lazy: Defer loading of the resource until it reaches a calculated distance from the viewport.
&gt; eager: Load the resource immediately, regardless of where it's located on the page.

Morten in 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:

+12 more
Tim Kaye

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.


@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.

Tim Kaye

@invisnet: Good. Thanks!

Tim Kaye

There's now a plugin that claims to do this: I am going to give it a try.

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.

Daniele Scasciafratte

I don't think that we should add this support because is not a standard yet and is supported only by Chrome

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.

Tim Kaye

@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.


Google has just released a plugin to do this:

"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.


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.


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. :)


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.


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