webp support for drimage

Created on 9 March 2021, over 3 years ago
Updated 29 September 2023, 9 months ago

Problem/Motivation

It would be great if drimage supports also webp if webp is enabled.

Proposed resolution

I checked out if this could work without big effort. With ImageAPI Optimize WebP β†’ webp generation works with image styles. This works also with drimage.

Remaining tasks

* Add a boolean option on drimage config if imageapi_optimize_webp is enabled, to enable webp. If not enable add help text and link to the modul
* Pass this option to the javascript
* Check this option in the browser and check if webp is supported by the browser
* If yes add a .webp suffix to the loaded URL. driamge/.../image.jpg.webp
* Inside the drimagecontroller check if the filename contains a webp. If yes pass webp as a file to the imagedownload controller.

I think it is not that hard to implement and it breaks nothing. Would you accept an patch?

✨ Feature request
Status

Fixed

Version

2.0

Component

Code

Created by

πŸ‡©πŸ‡ͺGermany Christian.wiedemann

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡§πŸ‡ͺBelgium kevin.vanbelle@skynet.be

    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 kevin.vanbelle@skynet.be

    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.

Production build 0.69.0 2024