WebP for all - not working as expected

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.

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.

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?

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.

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

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

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.

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

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

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.

@curenect-meiner

@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.

@dbu

Looking at the listing in the description, default_filter_set_settings: format: webp does work: d02cc7c2623b6fc1117bb11b8a3e18aa.png is reported by file as Web/P image. The default is merged into every filter set, and FilterManager encodes with the configured format. What makes it look like nothing happened is that the cached file keeps the source extension (.png), so the web server may also serve it as image/png. Combined with webp.generate, that same file is then encoded again into .png.webp.

@dbu would a PR that gives the cached file the extension of the configured format, behind a config option since it changes the cache paths, be what you had in mind? Or did you mean something else by changing the default?

imo the best solution is to use a srcset with one url for webp and a different url for the png or jpg. that way, images can be cached. solutions where the controller checks browser capabilities break caching because the response depends on not just the url but also browser headers that tell its webp capability.

in #1671 i experimented with the symfony ux image component that would give you a simple tag to render out the whole srcset. what do you think of that approach?

i am not too sure what i meant 1.5 years ago 👴 but saving the file with the correct extension for the determined format seems like a good idea regardless, yes.

@dbu

Thanks @dbu! The <picture>/srcset approach makes sense to me: one URL per format keeps every response cacheable and lets the browser pick, with no Vary: Accept involved. I like how #1671 maps each format to its own filter set variant (thumb_webp, thumb_jpeg...), it fits the way the bundle already works.

About the extension: while looking into it, I found that the bundle already has it as an opt-in decorator. FormatExtensionResolver (#1300) rewrites the extension to the format of the filter set in resolve(), store(), isStored() and remove(). It's only documented on its own page and has to be declared as a service by hand, so it's easy to miss (I did 😅).

So rather than a new option, maybe it just needs to be easier to reach: for example, registering it as a built-in resolver that decorates the default one, so cache: format_extension works without any service definition, and mentioning it in the WebP docs (and in the UX image docs of #1671, where each _webp variant would then be stored as .webp). Happy to open a PR for that if you think it's worth it.

yes, very glad if you want to do a pull request to improve the documentation, and make the behaviour a simple configuration instead of a custom service.

this whole additional formats has grown quite a bit after the initial concept. another thing i'd love to cleanup for version 3. i tend to prefer forcing the srcset approach because the content negotiation is just so messy with any sort of caching.

Navigation Menu

Repository navigation

WebP for all - not working as expected #1619

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

WebP for all - not working as expected #1619

Description

Activity

dbu commented on Feb 9, 2025

nacholibre commented on Feb 17, 2025

dbu commented on Feb 17, 2025

dbu commented on Feb 17, 2025

nibsirahsieu commented on Feb 20, 2025

tacman commented on Feb 21, 2025

darkomenx commented on Mar 13, 2025

tacman commented on Mar 13, 2025

curenect-meiner commented on May 11, 2025

dbu commented on May 12, 2025

Amoifr commented on Oct 9, 2026

dbu commented on Oct 15, 2026

Amoifr commented on Oct 19, 2026

dbu commented on Nov 8, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions