Hello. Under Umbraco 13 project, I have tried to add the following line: app.UseImageSharp(); to startup app code. Than I have added a test Document Type with Media picker property and a cshtml View to show it. Created a node of that document type, uploaded a jpg or png file to its media picker and published the page. Then I run the project, opened this page containing images (jpg or png) locally in Chrome browser and saw that for some reason the images are NOT receiving as webp (in Type column of Chrome's Network tab). Type column shows original jpeg or png type, and not webp as expected. NOTE: Earlier I used exactly the same flow under Umbraco 12 (added the same single line of code, without any additional settings) - and there it worked, so all the images are receiving as webp type (in Type column of Chrome's Network tab). Could you please advice how to achieve the same behavior under Umbraco 13 (with as less efforts as possible)? Thanks.

Hi Marian! Could you verify that the image urls in your browser have the ?format=webp query parameter added to it? Something like '/media/w4jmm5af/_0bae04f4-1c01-455d-9acf-5d042d8e542e.jpg?format=webp'

Hello Corné, ?format=webp query string is not added to image URLs. But I would like to skip it and make all the images receiving in webp format with original URLs (like it works for me in Umbraco 12, but does not work in Umbraco 13). Is it possible to achieve easily? if not - how to easily make adding that query string to all the images URLs? Thanks.

Due to the way ImageSharp works, it is necessary to indicate that it needs to convert images to Webp, just like it is necessary to add other optional parameters like croppings and quality modifiers. One of the ways you could do it automatically to all images is by adding a middleware that e.g. detects when a path starts with /media and ends with a type you want to convert (let's say .png), and then automatically adds the format=webp querystring to it. A very simplified (and not 100% foolproof) example could be something like the following

public class WebPConversionMiddleware
    {
        private readonly RequestDelegate _next;

        public WebPConversionMiddleware(RequestDelegate next)
        {
            _next = next;
        }

        public async Task Invoke(HttpContext context)
        {
            var request = context.Request;
            var path = request.Path;

            // Check if the requested URL ends with .png
            if (path.HasValue && path.Value.EndsWith(".png"))
            {
                // Append ?format=webp to the query string
                var newUrl = $"{path}?format=webp";
                context.Request.Path = newUrl;
            }

            await _next(context);
        }
    }
    }

Thanks for your answers. Will try somtthing like this.

Quick and dirty could also just be a urlrewrite rule?

though as Umbraco already has services.addImageSharp(), should it perhaps be...

builder.Services.AddTransient<IConfigureOptions<ImageSharpMiddlewareOptions>, CustomWebpImageSharpMiddlewareOptions>();

in a composer say to add your extra middleware? So as not to affect umbraco core? https://github.com/umbraco/Umbraco-CMS/blob/contrib/src/Umbraco.Cms.Imaging.ImageSharp/UmbracoBuilderExtensions.cs#L37 or maybe like this? https://github.com/umbraco/Umbraco-CMS/discussions/10840#discussioncomment-1166843

Thanks for your answers. Corne's idea worked for us.

Glad I could help! 🙂

While this converts your file format to webp, does it change the filename extension to webp? I have all images set to format=webp but Google Lighthouse, etc. still consider them jpg or png or whatever because the extensions aren't webp and marks you down. 😦

Interesting Craig mine are the same but lighthouse is happy. Is the mime type correct on your images?

As an alternative have you considered Cloudflare Polish (though only on cloudflare paid plans)? https://developers.cloudflare.com/images/polish/compression/

That's odd @Craig100 our Lighthouse tests seem to recognise the image as WebP and give it good scores https://cdn.discordapp.com/attachments/1226842197740093490/1233338008577638461/image.png?ex=662cbb07&is=662b6987&hm=ffb036a0b8d2018942b08e0681cd54744142217280cfa99274bc8738bbafc739&

MIne never have for years. I always use Slimsy to put out images (except for background images 😦 )

Sounds like it's not generating webp's for you. You can verify the formats in the network tab of dev tools, it should say webp in type: https://cdn.discordapp.com/attachments/1226842197740093490/1233340802525171822/image.png?ex=662cbda1&is=662b6c21&hm=6394a8064a548890f7ad095bb8194d7d32637dd355d513f901832557da47ac0d&

Oh the format IS webp alright, but the file extension remains as the original

yes that is expected, it's the server response that needs to be webp

Same https://cdn.discordapp.com/attachments/1226842197740093490/1233341349911334912/image.png?ex=662cbe24&is=662b6ca4&hm=94a012165ab51bd37acd4fa32990674f7730ff8810b16fbe849d6dafc2ab7796&

I've always assumed that it's why Lighthouse marks me down for not using webp's when what is being served IS a webp but is called a jpg or whatever.

We usually always use a custom extension method in views to render images for this very reason. But the

WebPConversionMiddleware

seems like it could cover more cases, including third-party images from packages/Forms etc.