Support » Plugin: EWWW Image Optimizer » Lazy load clarification

  • Resolved Gal Baras


    Just to clarify “lazy load (on ExactDN tab for now)”. Does this mean lazy load only works with images served via ExactDN or that the setting happens to be on that tab?

Viewing 15 replies - 1 through 15 (of 18 total)
  • Plugin Author nosilver4u


    It just means that the setting happens to live on that tab, it can be used by anyone.

    Thanks, @nosilver4u .

    Lazy load seems to work great.

    Where can I get more information on how it works, e.g. post-loading JS events, whether .htaccess rules are still used, etc?

    Plugin Author nosilver4u


    Not sure where .htaccess rules would come in with lazy loading, maybe you were thinking with the WebP stuff on that?

    As for the lazy loading itself, we use the lazysizes lib:

    Beyond just supporting src and srcset, the plugin also implements CSS background-image support on div and li elements, and automatic sizes calculation (to make responsive markup even more clever).
    All of that is built into lazysizes, then I’ve extended it a bit to use ExactDN to dynamically create exact-sized images for the background-image support and for any img elements that don’t have responsive markup.

    It also works well with JS WebP Rewriting (although ExactDN doesn’t need that anymore). Using Lazy Load + JS WebP helps avoid some layout issues I’ve seen sporadically (including on

    @nosilver4u thanks for explaining. I’ve done some testing with the new feature and I like it a lot so far.

    I saw a prompt to update .htaccess on the ExactDN tab, which seemed unrelated indeed. That’s why I asked. I’m guessing from the HTML code that the script requests the original image and the server will respond with the WEBP version, if available. That’s cool.

    Does the when JS WEBP rewriting option lazy-load CSS images?

    One thing I’ve noticed while testing was that the inline placeholder GIF was always square. I have some code to position images better in blocks and make the blocks the same height. For this to work, I prefer a placeholder in the same proportions are the images that will be loaded later.

    Can you make this happen? I’ve been able to do this in jQuery, but it’s probably best to have this done in the plugin for other people’s sake (and I have other sites).

    Thanks again,

    • This reply was modified 1 year, 5 months ago by Gal Baras. Reason: Removed WEBP script question
    Plugin Author nosilver4u


    Ah, the .htaccess prompt is simply because you have WebP conversion enabled, but the plugin can’t detect any rewrite rules and JS WebP is disabled.

    Both the .htaccess method and JS WebP work with our lazy load, and with the inline background-image style attributes.

    As for the placeholder, I don’t know if I’d call it square, more of a 1×1 dot, but I get what you’re saying. When ExactDN is active, it uses a low-quality placeholder which would achieve that sort of effect. Never tried to do that in JS though, do you have an example somewhere that I can reference?

    	attr_w = $(this).attr('width');
    	attr_h = $(this).attr('height');
    	w = $(this).width();
    	h = attr_h / attr_w * w;

    You can set height to ‘auto’ on ‘lazyloaded’, although I haven’t been able to figure out how to find the images that have just been loaded when this event fires

    • This reply was modified 1 year, 5 months ago by Gal Baras. Reason: Added event handler idea
    Plugin Author nosilver4u


    Could you just set the height to auto on img.lazyload instead? That you can do with plain CSS, no JS necessary, if that works.

    That’s a good idea, but it’s the easy part. The hard part is loading a responsive placeholder image. Sending a low-res image could be a good way to do it even from the site itself (i.e. with no CDN), perhaps even embedded in the page, like the placeholder is.

    Also, I still want to be able to only handle the images that have been loaded just now when ‘lazyloaded’ is triggered. In some cases, running the code on every image triggers redraws that are visible to the visitor and that’s no a good thing.

    Plugin Author nosilver4u


    Yes, you could do LQIP (low-quality image placeholders) without a CDN like ExactDN, but that’s not something I would ever recommend, as it has some serious performance implications.

    With the lazysizes library EWWW IO uses, you can use the lazybeforeunveil event to do custom actions. If you check includes/lazysizes-post.js from EWWW IO, you’ll see an example of how the plugin uses that hook/event.

    So this should work?

    document.addEventListener('lazybeforeunveil', function(e){ = 'auto';
    Plugin Author nosilver4u


    It should, but if that’s all you’re doing, couldn’t you just do that in CSS?
    Like so:

    img.lazyloaded {
        height: auto;

    Yes, of course I could do that, but I was hoping you would make it unnecessary for me to do anything by implementing a solution in your lazy loading code. Because I’m worth it 🙂

    @nosilver4u I’ve just figured something out. Setting the height in JS and then in CSS won’t work unless I use “!important”. But if I do that and the image actually needs some other height, that will be overridden.

    I suppose I could leave it alone, but what if the visitor changes the window size or flips the device 90 degrees?

    The best way would be to load an appropriately-sized image, or at least one with the correct aspect ratio, which you could perhaps create in PHP for the placeholder. So, instead of a 1×1 pixel gif, create a 320×245 pixel gif of some uniform color, which nobody will ever see anyway.

    One other bit of subtlety: images that should be visible above the fold, including CSS images, should be loaded as soon as possible. Since all embedded images have the lazy load markup, is there a delay from not leveraging HTTP/2 (or mod_pagespeed) optimisation? If so, the markup for those images should not be changed to allow the browser to optimise fetching them. I think it’s better to load an extra image immediately than to delay loading of the first image.

    The good news is that after some testing, your lazy loader seems to be noticeably faster than the Jetpack one (not sure why), at least when coupled with JS WEBP serving, so I am now using it on a large live site.

    Plugin Author nosilver4u


    The best way, as you mention, is to create a properly sized image in PHP, which is exactly what ExactDN does for you. It’s theoretically possible to package all that up into the plugin, but again, that’s not a route I’m currently interested in pursuing. At least not yet, because it’s a ton of work, and it all uses Gmagick, which isn’t very common across the WP ecosystem.

    If you want to have images above the fold load without any interference from the lazy loader, you can use the ewww_image_optimizer_lazy_fold filter. Just return the number of images you want excluded from lazy load.

    Can’t remember for sure, but I think the Jetpack lazy loader uses jQuery, so it’s possible lazysizes is faster because it uses all native JS, as does JS WebP in the latest versions.

    Plugin Author nosilver4u


    I have an idea. We’ve been stuck on the idea of generating a GIF in PHP, but what about an inline SVG. That takes virtually zero processing time, just need to get the dimensions (if known), and insert the markup.
    It would also potentially resolve the issue with incorrect sizes calculation, so I’m going to look into it further and see what I come up with.

Viewing 15 replies - 1 through 15 (of 18 total)
  • The topic ‘Lazy load clarification’ is closed to new replies.