- 🇧🇪Belgium kevinvb
I do see a minor issue with this.
So webp can be enabled in drimage settings when you have the ImageAPI optimize webp module enabled but even without it being enabled as soon as you use the background image handling option inside Dynamic Responsive image formatter the drimage.js logic will perform a check if the browser supports webp and tries to fetch an image.Wouldn't it be better that
Drupal.drimage.checkWebp();
is only called when you have webp support enabled?
- 🇧🇪Belgium weseze
@vbelle.kevin@gmail.com: Tanks for the feedback.
There was indeed a bug for background images, that they would always try and render webp if the browser supports it, regardless of drimage actually having support enabled.
I fixed that issue. ( https://www.drupal.org/project/drimage/issues/3389802 🐛 Bug for background images: they always try and render webp if the browser supports it. Fixed )Regarding the issue the checkWebp() function always running: that is intended since we want to know if the browser supports webp as soon as possible, without waiting for an actual drimage rendered image that needs webp.
The reasoning is documented in the JS:
// The webp check (for backgrounds only) is async. // The current JS is not written to properly handle async/promises. // So we will have to rely on the small timeout on the init function below. // If the delay is not enough, the script will simply render jpg/png instead of webp. // This is not what it should do, but it is acceptable until we can do a rewrite of the JS.If you have an idea/suggestion or patch/MR to address this issue, please open a new issue and share your work. Would be much appreciated!
- 🇧🇪Belgium kevinvb
Perfect I've updated the module in our project and now the delivery of image is faster because it doesn't always try to create a webp format and thus the image can now be delivered directly from apache instead of having to bootstrap Drupal every single time.
The JS logic that checks the support is indeed not really an issue, it doesn't have any impact.