Native Lazy Loading Support Coming to WordPress

It seems to be the week for dropping news of WordPress feature plugins. Felix Arntz, WordPress core committer and developer programs engineer at Google, announced a plan to push a lazy loading feature to the platform. If testing goes well, this feature could land in WordPress 5.4 in March.

The concept of lazy loading allows a webpage to render without loading certain resources until they are needed. This leads to faster page loads and saves data on the visitor’s end. Lazy loading is particularly useful when rendering images on the web.

The opposite of lazy loading is called eager loading, which loads everything in bulk. By default, this is how all images are loaded on the web. This often leads to poor performance on image-heavy webpages where many of the images are not in the site visitor’s viewport when first viewing the page.

For many years, various JavaScript libraries have handled this feature but not always to success. A native solution is slowly making its way into browsers. Native lazy loading works by adding a loading attribute to an <img> or <iframe> element. Browsers can then decide how to load a resource based on the value of the attribute. Currently, Chrome, Edge, and Opera all handle the loading attribute. Once the attribute officially makes it into the HTML specification, the feature should be a standard that all browsers support.

Adopting the new loading attribute is a great chance for WordPress to lead the way for a faster web overall.

Felix Arntz

The new Lazy Loading feature plugin is now available in the WordPress plugin directory. The plugin relies only on native browser support and does not add extra JavaScript. The implementation adds a loading attribute to images in post content, excerpts, comments, text widgets, avatars, and instances of using core WordPress image functions. By default, the plugin sets all images to load lazily rather than eagerly.

It is refreshing to see the continued work by core contributors on more robust image solutions. Along with WordPress 5.3’s large image size handling, both features will lead to a generally faster web. With more users loading high-quality images via mobile phones over the past few years, it has only exacerbated the problem of a slow web. That is why it imperative that WordPress continually push for image optimization.

“With WordPress enabling native lazy-loading by default, it would significantly impact performance and user experience for millions of sites, without requiring any technical knowledge or even awareness of lazy-loading as a concept,” wrote Arntz in the announcement post. “Adopting the new loading attribute is a great chance for WordPress to lead the way for a faster web overall.”

Arntz and a team of engineers originally released a native lazy loading plugin in September 2019. This was shortly after Google brought the “loading” attribute feature to version 76 of its Chrome browser. The Native Lazyload plugin currently has over 7,000 installations.

How This Affects Existing Plugins

Because not all web browsers support the loading attribute, users may not want to automatically drop their current plugins when the feature lands in WordPress. Users may choose to support browsers without native lazy loading for a while

The proposed code within the Lazy Loading plugin attempts to detect whether the loading attribute exists on an image before applying it. This means the code should play nicely with existing plugins and avoid conflicts in most cases.

Developers of plugins that handle lazy loading need to start testing their plugins and updating them for WordPress 5.4. Follow the Lazy Loading API ticket on core Trac to stay updated on when the feature lands and the GitHub repository for contributing to its development.

14

14 responses to “Native Lazy Loading Support Coming to WordPress”

  1. Remy says:

    The big issue with native lazy load currently in Chromium is the thresholds values used: images start to be lazy loaded only if they are 3000 to 8000 pixels below the fold, depending on your connection type: https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/frame/settings.json5?l=971-1003&rcl=e8f3cf0bbe085fee0d1b468e84395aad3ebb2cad

    These values are huge, especially compared to what is currently used by most lazy load plugins out there.

    If someone was not using a plugin for that before, it will go from no changes to a possible improvement, but If they switches from a plugin solution to the native solution after 5.4, they might in fact face a decrease of performance and loading time on their website, instead of an expected increase.

    Report

    • Chris says:

      So that’s why when I used the native lazy loading plugin from Google it seemed like it wasn’t working! That’s a pretty big issue… do they consider that a bug?

      Report

  2. Bravo Felix!

    Imagify, are you listening? ;-)

    Report

  3. Brin Wilson says:

    What if someone scrolls down a post very fast – skimming it, or scrolling to get to specific sections – will they have to wait a few seconds for the images to load? This can be very very irritating…

    Report

  4. Peter says:

    What is the point in trying to push it into 5.4 right now?

    I mean for years WP did not do anything in this regard despite there were requests.

    Now as most browsers will implement it natively, WP tries to win the race and implement it first.

    A great way to waste resources, congrats! Less PR stuff would be real beneficial for WP.

    Report

  5. Arūnas says:

    While I am happy to see that some kind of lazy-loading is coming to Core and it is a good feature to have. I’m just not that sure about the timing of this. Despite the nice wording around it in the post, this is not yet part of WHATWG specification and only one rendering engine actually supports it. So this seems like a bit of putting the wagon before the horse. One might also see this as using the weight of WordPress to push through a feature that has not seen a wide adoption among browser vendors, yet. Firefox is nowhere near supporting this yet, for example.

    Report

    • Rainer Grübelzki says:

      It’s a “googleguy” project, similar to that brandnew never seen before XML sitemap thingie. It will be pushed, no matter if it is ready oder useful for general public. People will have lots of issues with existing “lazy loading” features in all kind of plugins, but nobody cares about that, such issues will be closed with “contact third party vendor” in issue trackers, been there, seen that.

      Report

    • gerdneumanngerd says:

      Exactly. This is yet another push by Google pushing their browsers and market share. I am very worried to see how Google gets involved into WordPress development to add features that only the engine supports that Google controls. Firefox and diversity will be the looser. In the end the free www as we know (knew?) it.

      I am all for the lazy loading feature, but there are valid points why this is not an official standard yet. (And the way chromium implements it !== a standard)

      Report

  6. It’s a good feature to have, but what I don’t agree with is checking to see if there already is a loading attribute before adding it. Checking this for thousands of images would definitely slow down everything.

    Why not assume there’s no loading attribute and add it automatically? This way, there won’t be any duplicate functionality with plugins. Also, if there’s a plugin adding this attribute, which one will have higher priority?

    Report

    • If anyone is loading thousands of images on a webpage, I don’t think their primary speed-related concern is going to be with a PHP check for the loading attribute.

      Not performing the check would conflict with hard-coded loading attributes on existing images. It would be poor coding practice to attempt to push an attribute to an HTML element without first making sure it doesn’t already have that attribute.

      As for the priority between core and plugins, it will ultimately depend on the priority used for filter callbacks.

      Report

      • Thanks Justin. I was only concerned about this extra check, as core lazy loading should take priority over everything. Existing JavaScript-based plugins are doing it differently anyway, by using a data-src attribute and a 1px image or a placeholder and then replacing everything if they are within visible threshold. This would also clean up (weed out) older plugins.

        I’m sure the speed gain is negligible, but every millisecond counts, especially with Google’s move towards shaming slow websites.

        Report

  7. Tim says:

    Native support for lazy loading would be a nice feature. The current plugins mostly use Javascript to support lazy loading and this could cause the problem that images are not loaded at all.

    Last week I have disabled lazy loading in the WP Smush plugin because images are not loaded in WordPress with a specific theme.

    Report

  8. Wondering how it impact speed plugins like WP Rocket.

    Report

  9. Shrinivas says:

    The WordPress dev team has now moved this feature to WordPress 5.5 as 5.4 beta is already out. So we can’t expect this feature in the upcoming WordPress update.

    Report

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: