Support » Plugin: EWWW Image Optimizer » JS WebP loading both .jpeg and .webp version of image

  • Resolved Will Stocks


    Me again!

    So, I’ve noticed that for most images both the webp and original .jpeg/png version is being loaded.

    For instance, if you take a look at my homepage and monitor the network tab (in Chrome) for images and filter it down to one of the following:


    You will see that both the 100x**.jpg and 100x**.jpg.webp versions of the file are being loaded immediately upon page load (I use lazysizes with a LQIP version of the image in the src).

    Would this be resolved by me removing src and replacing it fully with data-src?

    The page I need help with: [log in to see the link]

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


    Yeah, the JS WebP is going to let your LQIPs load, and then load the WebP versions. That’s why our lazy loader uses blank PNG versions of images rather than just a small version of the image. Though our ExactDN does do LQIP, it uses a different implementation with far lower quality to make sure the placeholders are all under 10kb each. And even then the placeholders are never using WebP.

    All that said, I wouldn’t necessarily remove the src attribute, as that can cause some layout issues, but it wouldn’t hurt to try out lazy loader instead and see how you like that.

    Hmmmm, interesting!!!

    But why would JS WebP allow my jpeg LQIP loaf… then reload that exact same image as WebP, if the jpeg has already loaded?

    I wouldn’t want blank placeholders, I’d still want LQIP. I will investigate ExactDN (I’ve briefly looked but haven’t had huge amounts of time so far), but is there anything I can do in the meantime to prevent the extra, unnecessary request?

    I will investigate ExactDN

    Would you recommend me looking at replacing CloudFront with ExactDN (in front of S3) or going full, direct ExactDN (no S3)?

    Plugin Author nosilver4u


    Whatever is in the src attribute will always load, JS WebP doesn’t know those are the same two images. Normally, the placeholders would be something much smaller, it’s just in this particular case that the two are the same image in two different formats. Most of the time, that’s not going to be the case, and you won’t really have an “extra” request.

    In your case, I would definitely replace Cloudfront with ExactDN, so that you have ExactDN pointing directly to S3. It would make JS WebP unnecessary also.
    Since that’s a paid product, any further discussion on ExactDN needs to happen via email (rather than on the free forums):

    OK… I think I’m with you.
    Just so I fully understand:

    Is it that the src (jpg) and then data-src (jpg.webp) are being loaded, before lazyloading sets in and then loads the data-srcset?


    Is it that the src is being loaded as .jpg, then JS WebP is kicking in and reloading it as .jpg.webp?

    I will drop you an email shortly, thanks 😀

    Plugin Author nosilver4u


    It would be the latter. If there IS a data-srcset, then only the src and data-srcset should ever be loaded by a browser when you use lazysizes. But in either case, the src always gets loaded.

    So the src will always be loaded twice and there’s no way for me to prevent that without using ExactDN?

    Plugin Author nosilver4u


    Even ExactDN will load both the src and data-src (that’s how lazy loading normally works), but it will use smaller LQIPs in the src, rather than just a 100px version of the image. In the case of a 100px image, you will actually get blank 100px placeholders. Anything under 10kb (or smaller than 200×200) gets a blank image rather than a real LQIP for efficiency sake.

    But if I’m using src with a data-srcset for responsive image lazyloading (lazysizes), then loading the data-src isn’t strictly necessary, is it?
    So is there anyway for me to remove the data-src but still have JS WebP convert my data-srcset values (the first time I tried without, it didn’t run)?

    Plugin Author nosilver4u


    If you have data-srcset, then yes, the browser pretty much ignores the data-src, but the JS WebP parser won’t do anything to the images without the data-src.

    Lol, forgive me then – I’m still getting confused. So, I have three images being called:

    lqip.jpg = src
    lqip.jpg.webp = ??? (data-src or repeated src)
    fullsize.jpg.webp = data-srcset

    If the data-src is ignored because there’s a data-srcset, that means that the lqip.jpg is being loaded (as expected) but then JS WebP is loading it again for some reason, even though the jpg has already been loaded? What would be the reason for that if the jpg is already loaded?

    Plugin Author nosilver4u


    lqip.jpg.webp should never be in play here. You can’t use a conditional LQIP, since the src (lqip.jpg) will already be loaded. The data-src should point to the original image (or perhaps a large/medium version of that image).

    From what I can see, the confusion is stemming from a handful of images where the “original” image is a 100px thumbnail, thus lqip.jpg == fullsize.jpg, and you end up loading both a JPG and WebP version of those tiny images.

    That is, of course, undesirable, but a solution within the constraints of LQIP is difficult.
    With your current lazysizes implementation, there are a couple ways to make it better:
    1. Use a standard inline GIF placeholder, since 100px images aren’t really being lazy loaded otherwise. That then opens the door for you to still apply JS WebP on them.
    2. Skip doing WebP, or skip lazy load, but don’t try to do both.
    –If you skip JS WebP on 100px images, you just get the original 100px JPG, if you skip lazy load, then you should get a WebP image via JS WebP.

    OK – I _think_ I’m with you now!

    I’ve checked on a page where I have posts that don’t collide with my “Recent Posts” section ( as an example) and I can see that if I filter the loaded images down to “DNS”, that only the lqip.png + lazyloaded-full.webp are loaded (woooo!). I was about to ask “could I just set data-src="" (blank) so JS WebP would still work with just src and data-srcset” but I don’t think it’s necessary, so that’s good!!

    That being said, the behaviour is not the same on Safari (macOS Safari 12.1.2) – I’m seeing lqip.png + lqip.png + lazyloaded-full.png + lazyloaded-full.png (duped image requests, obviously not WebP because no support) in the network waterfall… I assume that JS WebP is causing this somehow?

    Plugin Author nosilver4u


    I think that’s just a quirk of the Safari dev console when caching is disabled. With caching, it only loads (from memory) once.
    At any rate, the markup looks correct to me, looking at the raw source, the element after being parsed by JS WebP, and then the final element lazy loaded.

    Plugin Author nosilver4u


    One other possibility is that the “blur up” technique could be causing this. If I remember right, a “blur up” loads the image before actually inserting it into the src/srcset attribute. Then, once the image is fully constructed by the lazy loader, you’d probably get another load event, though it should just be the same image loading again. I think that is the most likely explanation, even though Chrome doesn’t seem to display the double-request for some reason. And of course, it’s the same image, so it’s never actually going to load twice, it’ll be cached after the first request.

    Especially on a browser like Safari (in conjunction with lazy load), JS WebP doesn’t actually do anything except remove it’s ewww_webp_lazy_load class, so any “quirks” are more likely to be from the lazy loader itself.

Viewing 14 replies - 1 through 14 (of 14 total)
  • You must be logged in to reply to this topic.