Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WebP for all - not working as expected #1619

Open
nacholibre opened this issue Jan 27, 2025 · 6 comments
Open

WebP for all - not working as expected #1619

nacholibre opened this issue Jan 27, 2025 · 6 comments

Comments

@nacholibre
Copy link

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
Copy link
Member

dbu commented Feb 9, 2025

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
Copy link
Author

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
Copy link
Member

dbu commented Feb 17, 2025

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
Copy link
Member

dbu commented Feb 17, 2025

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
Copy link

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

@tacman
Copy link
Contributor

tacman commented Feb 21, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants