WebP for all - not working as expected

[nacholibre]

I have a project with images in jpeg or png format.

I want to migrate all images to WebP format with a 301 redirect. My goal is to reduce image size without compromising quality and keep search engines ranking by doing a permanent 301 redirect.

According to the documentation doing this:

# app/config/config.yml

liip_imagine:
    default_filter_set_settings:
        format: webp

Should force all images to be converted to webp when any filter is used, however I'm not getting it. This option above does nothing.

I can get WebP images only if I include

# app/config/config.yml

liip_imagine:
    # configure webp
    webp:
        generate: true

But this causes generation of two images and resolving is called each time when an image is showed on a page. Even after the filtered image is created and the image is stored on the disk resolve is called each time. I'm assuming this is done to detect browser headers and support for WebP?

Also I'm noticing that images are bigger once when are converted to webp which is really odd? Filtered images are the same resolution.

total 648
drwxrwxrwx@ 10 nacholibre  staff   320B Jan 27 14:41 .
drwxrwxrwx@  6 nacholibre  staff   192B Jan 27 13:30 ..
-rw-rw-rw-@  1 nacholibre  staff   5.8K Jan 27 14:19 14434c84d296ccd05efb7580f3478ef1.png
-rw-rw-rw-@  1 nacholibre  staff    16K Jan 27 14:20 14434c84d296ccd05efb7580f3478ef1.png.webp
-rw-rw-rw-@  1 nacholibre  staff    68K Jan 27 14:19 5444edc8316cbd4c175acb1352186784.webp
-rw-rw-rw-@  1 nacholibre  staff   161K Jan 27 14:20 5444edc8316cbd4c175acb1352186784.webp.webp
-rw-rw-rw-@  1 nacholibre  staff    12K Jan 27 14:41 939c2a2427ef8ddef453aaa32702c11a.jpg
-rw-rw-rw-@  1 nacholibre  staff    21K Jan 27 14:41 939c2a2427ef8ddef453aaa32702c11a.jpg.webp
-rw-rw-rw-@  1 nacholibre  staff   6.4K Jan 27 14:19 d02cc7c2623b6fc1117bb11b8a3e18aa.png
-rw-rw-rw-@  1 nacholibre  staff    16K Jan 27 14:20 d02cc7c2623b6fc1117bb11b8a3e18aa.png.webp

$ file d02cc7c2623b6fc1117bb11b8a3e18aa.png: RIFF (little-endian) data, Web/P image, VP8 encoding, 300x300, Scaling: [none]x[none], YUV color, decoders should clamp
$ file d02cc7c2623b6fc1117bb11b8a3e18aa.png.webp: RIFF (little-endian) data, Web/P image, VP8 encoding, 300x300, Scaling: [none]x[none], YUV color, decoders should clamp

These tests are done on a local test environment with PHP 8.1, Symfony web server and imagine-bundle version 2.13.3.

My questions are:

• How to get all images converted to webp?
• Why are the webp images bigger than their jpg/png originals?

Thanks for your time building and supporting this library. I appreciate your efforts.

[dbu]

when webp handling was introduced in this bundle, the feature was still rather experimental and older browser versions did not support it. so the approach was that the request for the normal image detects the webp support to decide which image the user gets. afaik, even today it is not considered best practice to always deliver webp without checking browser capabilities.

the problem is, many sites use a reverse cache to cache the rendered html pages, so the twig function to generate the image src attribute is not the right place to check on browser capabilities. thus the .png url is rendered, and the image controller decides which format to redirect to.

this is however indeed creating a lot of hassle. lately, i have been thinking if there is a way to move the decision between png and webp to the client, similar to how responsive images of different resolutions can be decided on the client to support very high resolution displays.

i would be very open for suggestions, both work arounds or also BC breaking changes for a new major version that we are thinking about.

[nacholibre]

According to caniuse webp format has 96.53% support from browsers, which for me is enough to introduce it without backwards compatibility.

What does this option do?

# app/config/config.yml

liip_imagine:
    default_filter_set_settings:
        format: webp

If I understand correctly this should force all thumbnails to use webp format no matter the source format?

[dbu]

afaik webp handling in the current version of the imagine bundle has magic all over the place to check browser capabilities and fallback to other formats.

i think for the next major version, we should remove all the special handling as it creates a lot of confusion for not much value.

[dbu]

there seems to be a way to specify both jpg and webp to the browser, which would make things robust and get rid of all needs to redirect: https://css-tricks.com/using-webp-images/#aa-using-webp-in-html and type in css: https://developer.mozilla.org/en-US/docs/Web/CSS/image/image-set#using_image-set_to_provide_alternative_formats

[nibsirahsieu]

I experienced this issue awhile ago, i managed to fixed by using this method.

[tacman]

In my application, I'm bypassing the automatic generating of the resized files in the controller (I kept DoSing my own server with a large number of thumbnails). My service that runs async through messenger uses this to creates the webp file.

	public function __construct(
        #[Autowire('@liip_imagine.service.filter')] private readonly FilterService $filterService,

        // this actually _does_ the image creation and returns the url
        $url =  $this->filterService->getUrlOfFilteredImage(
            path: $path,
            filter: $filter,
            resolver: null, 
            webpSupported: true
        );

I know this method name is a candidate for being renamed in the next version, it does a lot more than simply get the url.

    default_filter_set_settings:
        format: webp
        quality: 68

This generates just the webp files. The name is still .jpg though. webp is so much smaller that it's worth losing the small percentage of browsers that don't support it.

[darkomenx]

but why webp image generated is more heavy than original jpg file ?

[tacman]

hmm. That's not my experience. I've been blown away with how good webp is. I get decent thumbnails at about 1500 bytes.

[curenect-meiner]

yes i do the same.
Build my own functions with webp and avif.
Liip nearly support webp.
They wont fix the bug, that webp images wont be generated automaticly, so you have to do it by yourself.

[dbu]

@curenect-meiner if you can do a pull request to change this without a backwards compatibility break (either there is a solution that can change the default, or we do a feature flag in the configuration to enable the new behaviour) i am happy to review it.