14 Comments

  1. Remy

    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

      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. Marcus Tibesar

    Bravo Felix!

    Imagify, are you listening? ;-)

    Report

  3. Brin Wilson

    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

    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

    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

      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

      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. Ciprian Popescu

    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

    • Justin Tadlock

      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

      • Ciprian Popescu

        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

    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. Vladimír Juroško

    Wondering how it impact speed plugins like WP Rocket.

    Report

  9. Shrinivas

    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

Comments are closed.

%d bloggers like this: